Skip to content
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

Merged
merged 1 commit into from
Aug 24, 2024

Conversation

asarhaddon
Copy link
Contributor

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).

Copy link
Owner

@kanaka kanaka left a 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).
@kanaka kanaka merged commit 87b283a into kanaka:master Aug 24, 2024
110 of 112 checks passed
@kanaka
Copy link
Owner

kanaka commented Aug 24, 2024

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

@asarhaddon
Copy link
Contributor Author

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, case [a,b] and case (a, b) are equivalent and both match any iterable object with two elements, not only lists and tuples respectively.

The authors have always said that python3 was a distinct new language. I fully support the name change.

@asarhaddon asarhaddon deleted the python branch August 26, 2024 11:45
asarhaddon added a commit to asarhaddon/mal that referenced this pull request Aug 26, 2024
asarhaddon added a commit to asarhaddon/mal that referenced this pull request Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants