-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python.2: fix tests, use source checkers and more python3 features #665
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like ubuntu:bionic has python 3.6.9 which doesn't have dataclasses builtin. Is this one that wants to be updated to Ubuntu 24.04?
I've been out of the loop on python3 language changes in the past few years. The pattern matching construct and optional typing look really nice.
Regarding the python implementations: I think it is interesting and worthwhile to support legacy languages. Also, impls/python
was one of the first 5 original implementations so I'm a bit nostalgic for it 😄. Ubuntu 22.04 is an LTS that is supported until Apr 2027 so it won't start being harder to test python2.7 it until after that.
However, I would be fine with treating python2 and python3 as different implementation languages (modern python3 features effectively make it a different language from python2). I think what that would mean is that impls/python/
would be renamed to impls/python2/
(and then the python3 MODE and code could be removed from that implementation) and this implementation (impls/python.2
) would be named impls/python3/
. Does that sounds like a reasonable plan? If so, let's get this PR working as is and then do that renaming/cleanup as a separate PR.
Check the whole code with flake8, pylint and mypy. Report all possible errors with extensive context. Demonstrate iterators, decorators, functional tools, chain maps, dataclasses, match statements, assignments expressions. Implement environments with python chain maps. Rewrite the reader without external dependencies (but inspired by the ptk library). The motivation was that no external library is fully type-checked for now. Avoid name clashes when possible (print, read, readline, types). Write the readline history file at exit, not after each prompt. Replace printer.pr_str as methods of MAL objects. This is idiomatic python, and improves the error reporting. Change some representations so that the python equality matches the MAL equality. The recursion is now implicit. Remove -O from ./run. It took me a while to understand that run-time assertions were disabled! MAL is about development, not performance. Dispatch the special forms from a dict, for readability (pylint rightfully complains that there are too many return statements in eval_()). Copy the recursion overflow fix, the python interaction from the first python implementation. Add tests detecting that nil false 0 () [] "" are distinct, and that 0 () are not False when tested (in python False == 0 and an empty container is tested ). Add tests checking that metadata does not affect equality (they do with a naive python dataclass).
Looks like the new tests have revealed some issues in elisp and powershell. I decided just to merge this and I've filed a ticket to track the failures in those implementations: #667 |
These two features are quite impressive, especially taking into account that the original language design seemed incompatible. As usual in python, both are the result of compromises and slightly differ from what you could expect in a strongly typed language. For example, The authors have always said that python3 was a distinct new language. I fully support the name change. |
I have almost rewritten the python.2 implementation, but in the same direction and based on the work by @epylar. I suggest to merge all the ideas he agrees with.
The most intrusive suggestion is the removal of an external parser library. The MAL grammar is so simple that a parser does not help much, and general libraries are difficult to type-check.
Also, the impls/python.2/tests/*.py are out of sync (and were before this suggestion). Are they useful after the initial development? If we update them, Makefile should run them.
By the way, python.2 belongs to the past now. Should we not merge the two python
implementations?
Changelog:
Check the whole code with flake8, pylint and mypy.
Report all possible errors with extensive context.
Demonstrate iterators, decorators, functional tools, chain maps, dataclasses, match statements, assignments expressions.
Implement environments with python chain maps.
Rewrite the reader without external dependencies (but inspired by the ptk library). The motivation was that no external library is fully type-checked for now.
Avoid name clashes when possible (print, read, readline, types).
Write the readline history file at exit, not after each prompt.
Replace printer.pr_str as methods of MAL objects. This is idiomatic python, and improves the error reporting.
Change some representations so that the python equality matches the MAL equality. The recursion is now implicit.
Remove -O from ./run. It took me a while to understand that run-time assertions were disabled! MAL is about development, not performance.
Dispatch the special forms from a dict, for readability (pylint rightfully complains that there are too many return statements in eval_()).
Copy the recursion overflow fix, the python interaction from the first python implementation.
Add tests detecting that nil false 0 () [] "" are distinct, and that 0 () are not False when tested (in python False == 0 and an empty container is tested ).
Add tests checking that metadata does not affect equality (they do with a naive python dataclass).