1.0 Feature Lock

[allison-casey]

On the way to Hy 1.0 I think we need to lock down what we consider priority items to prevent feature creep and help us get 1.0 out the door sooner while we have some momentum. I've gone through the entire outstanding issue list and categorized what I think are necessary features/bugfixes as well some some things we might want to include in 1.0 but I want to get more discussion on. Feel free to dispute the categorizing of any of these issues. Some of them may also have been fixed, but just never got updated so if you see one of those you know is fixed let me know. A lot of these still need some discussion as to how we want to deal with them, but that discussion should take place in their respective issues. this is just to figure out what we want to focus on.

Necessary Features

• Position information for generated models #741 better syntax errors for debugging macros (still issue?)
• Don't include the namespace in the import's name for hy models. #1644 don't include the namespace in the import's name for hy models
• Remove internal importlib frames from traceback #1693 remove internal importlib frames from traceback (still issue?)
• Support the Windows "embeddable zip file" releases of Python #1856 support windows "embeddable zip file" release of python
• The great core shakeup #1992 great core shakeup

Necessary Bugfixes

• .pyc files don't get recreated when they use a macro from a file that was changed #1324 pyc files don't get recreated when they use a macro from a file that was changed (absolutely need to fix this)
  • Support user introspection and modification of the currently defined macros #1467 byproduct of .pyc files don't get recreated when they use a macro from a file that was changed #1324
• Automatic imports can shadow the user's assignments in the REPL #791 autoimports shadow assignments (stopgap fix in pr Implement Hy builtins as actual builtins #1979)
• eval can only see locals #1041 eval can't see locals (fixed but needs a test to close)
• NameError for HyList, HyDict ... #1045 NameError for HyList etc (stopgap fix in pr Implement Hy builtins as actual builtins #1979)
• Hy models have wrong equality #1363 Hy models have wrong equality (= 'hello "hello") etc
  • unquote-splice interacts with HySymbol weirdly #1509 unquote-splice interacts with HySymbol Weirdly
• On Windows, REPL fails to start if there's a non-ASCII character in .hy-history #1535 On Windows, REPL fails to start if there's a non-ASCII character in .hy-history (still issue?)
• Pygments Hy lexer needs improvements #1541 Pygments Hy lexer needs improvements (not actionable until 1.0?)
• Get rid of the __init__ return suppression automagic and replace with a definit macro #1544 get rid of __init__ return suppression automagic (still an issue?)
• Mangling changes broke REPL completer #1564 mangling changes broke compiler (still an issue?)
• hy-repr mishandles lexically illegal symbols and keywords #1617 hy-repr mishandles lexically illegal symbols and keywords
• Macro name shadowing/collisions and removal #1689 macros name shadowing/collisions and removal
• Hy repl doesn't open on clean install python 3.7 #1690 hy repl doesn't open on clean install python3.7 (still issue?)
• Macros do not like unpack-mapping #1730 macros do not like unpack-mapping
• Slow startup when Hy is installed from a wheel #1747 slow startup when Hy is installed from a wheel
• Unable to import Pip-installed & Conda-installed modules in Anaconda managed VirtualEnv environments #1823 unable to import pip-installed & conda-installed modules in anaconda managed venv
• hy-repr probably shouldn't use the registered function of a supertype #1873 hy-repr shouldn't use the registered function of a supertype
• require with relative path crashes the compiler #1897 require with relative path crashes the compiler
• curses and SIGWINCH do not work properly with Hy. #1921 curses and sigwinch do not work properly

Maybe Features

• Namespaced symbols #277 namespaced symbols
• Decorators are ugly #952 decorators ugly, maybe bring in to fn form with something like @[dec1 dec]
• Support for python -m package.module with package/module.hy. #1018 make hy work with python -m package.module (is this possible?)
• Consider extending Hy's . form to accept calls #1108 extend . to accept calls
• hy -i should support the debugger #1395 hy -i should support the debugger
• Get rid of autoimports via new namespaces #1407 get rid of autoimports viw new namespace (stopgap fix in Implement Hy builtins as actual builtins #1979)
• Support more of CPython's command-line options #1488 support more of CPython's command-line options
• Expose pytest integration as a plugin #1526 make pytest hy plugin
• #1611 #, tuple tag macro
• import syntax improvements #1612 import syntax improvements
• Leading - should not get converted to underscores. #1635 mangle leading - differently to prevent them from becoming module private
• Turn require into a macro #1692 turn require into a macro
• Make the inspect module compatible with Hy #1696 make inspect module compatible with Hy
• Inconsistent for syntax #1723 inconsistent for/comprehension syntax
• Hy sys.executable may confuses python library #1753 sys.executable confuses python libraries
• A gotcha in keyword mangling #1765 don't mangle hy symbols that collide with python reserved words
• Perhaps call multiprocessing.set-executable at startup #1786 call multiprocessing.set-executable at startup
• Pattern Matching #1954 pattern matching support (python 3.10)

[peaceamongworlds]

It seems like #1978 is also currently fixed by #1979

[peaceamongworlds]

Also, do we have a target date for when we want to get 1.0 out? Or are we going to release 0.21 before then anyway?

[allison-casey]

there hasn't been any discussion about a target date. I brought up in #2003 that i think we should move to pre-releases for 1.0 so we don't keep breaking people's code with intermediate versions. If we do that, do we want to pin pypi Hy at 0.20 and make our next release 1.0a1, pin at 0.21 and start pre-releasing after that, or don't do pre-releases at all and continue pushing to main release line?

[peaceamongworlds]

I don't know how this is normally done, so my opinion shouldn't be taken too seriously.

I agree that pinning it at 0.20 for a while is a good idea. The language currently is very usable, and while it does have a few rough edges, it seems like they can be avoided. What we want to do with future releases I think heavily depends on how quickly we can get to 1.0. If we can do it within a relatively short time-frame (say 6 months), I don't really see the point of changing the current release cycle. Once we get to 1.0, then we could reconsider this again.

[allison-casey]

It's a good point. We've managed to get a lot done on master that have gotten us a lot closer to 1.0 (only changes to core and and fixing the pyc issues are major outstanding issues) that a pre-release cycle might not be necessary. If this was 6 months ago I'd probably be more forceful on this front, but if we get through there rest of the necessary issues in 6 months we might as well just not push a 0.21 release and wait til 1.0 instead. From there I think we should definitely go with a pre-release cycle like python does (i.e. python3.10 is on alpha 6 right now). There's also a lot we can do from there like deprecation warnings and shims once Hy's syntax has settled down, but that discussion can wait till 1.0.

[peaceamongworlds]

Yeah, I agree. It seems like getting 1.0 should be our priority for now.

[allison-casey]

I'm going to move these issues into the 1.0 Project Board so I can keep track of how things are going.