-
-
Notifications
You must be signed in to change notification settings - Fork 32k
gh-125331: Allow the parser to activate future imports on the fly #125482
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
Conversation
Eh, not sure if this is desirable, maybe lock the future behind a repl compiler flag: # tmp.py
from __future__ import barry_as_FLUFL
1 != 2 $ gh-125331/python.exe tmp.py
File "/Users/wannes/Documents/GitHub/cpython/tmp.py", line 2
1 != 2
^^
SyntaxError: with Barry as BDFL, use '<>' instead of '!=' This is great though: >>> from __future__ import barry_as_FLUFL
... 1 <> 2
...
True |
This change isn't backwards compatible, although it only affects 14 files (Github search). |
I feel it should work like any other future import, so it can serve as an example.
I feel those people are asking for it; they're using an undocumented joke feature. We can limit this change to 3.14 though. |
The whole point of this is that it works everywhere, not just in the REPL
haha, we need to decide if is a bug or if is not. If we decide this should work everywhere the fact that those people are using is fixing the bug. In the issue I said I don't think this is a bug, but if we decide that it is, then it is not backwards incompatible: it's fixing a bug. Notice there is no documentation about how this is supposed to work and all observable behaviour is not protected for backwards compatibility. |
cc @warsaw |
How about the multiple-name imports? from __future__ import annotations, barry_as_FLUFL
x: A
print(__annotations__['x']) # A
print(1 <> 2) # True If I'm looking at the code correctly, it only accepts single-name imports for now.. |
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.
I'm generally okay with this, I think we do some similar hacky things elsewhere.
A couple of minor comments.
Yeah, the PR is only a draft for evaluating the idea, is still missing many things like tests, NEWs...etc |
cd167c2
to
8fb86b3
Compare
@lysnikolaou can you take another look? |
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.
LGTM! 🎉 A couple of very nitty comments. Feel free to diregard.
Misc/NEWS.d/next/Core_and_Builtins/2024-10-29-23-30-35.gh-issue-125331.quKQ7V.rst
Outdated
Show resolved
Hide resolved
Misc/NEWS.d/next/Core_and_Builtins/2024-10-29-23-30-35.gh-issue-125331.quKQ7V.rst
Outdated
Show resolved
Hide resolved
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.
Thanks Pablo & Jelle for answering my questions!
Misc/NEWS.d/next/Core_and_Builtins/2024-10-29-23-30-35.gh-issue-125331.quKQ7V.rst
Outdated
Show resolved
Hide resolved
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.
Someone alluded to it above, but this incorrectly picks up relative future imports:
>>> from .__future__ import barry_as_FLUFL; 1 <> 2
Traceback (most recent call last):
File "<python-input-4>", line 1, in <module>
from .__future__ import barry_as_FLUFL; 1 <> 2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named '_pyrepl.__future__'
True
>>> from .__future__ import barry_as_FLUFLx; 1 <> 2
File "<python-input-5>", line 1
from .__future__ import barry_as_FLUFLx; 1 <> 2
^^
SyntaxError: invalid syntax
The first one correctly throws ModuleNotFoundError, but it also allows 1 <> 2
. The second one throws a SyntaxError as expected.
Co-authored-by: Lysandros Nikolaou <[email protected]> Co-authored-by: Nice Zombies <[email protected]> Signed-off-by: Pablo Galindo <[email protected]>
Co-authored-by: Lysandros Nikolaou <[email protected]> Co-authored-by: Bénédikt Tran <[email protected]>
…e-125331.quKQ7V.rst Co-authored-by: Bénédikt Tran <[email protected]>
Co-authored-by: Nice Zombies <[email protected]>
…e-125331.quKQ7V.rst Co-authored-by: Jelle Zijlstra <[email protected]>
…gh-issue-125331.quKQ7V.rst
@JelleZijlstra I have fixed the relative imports, rebased and added a test, can you review it again? |
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
…ly (pythonGH-125482) (cherry picked from commit 3bd3e09) Co-authored-by: Pablo Galindo Salgado <[email protected]>
GH-131062 is a backport of this pull request to the 3.13 branch. |
…ly (pythonGH-125482) (cherry picked from commit 3bd3e09) Co-authored-by: Pablo Galindo Salgado <[email protected]>
GH-131063 is a backport of this pull request to the 3.12 branch. |
from __future__ import barry_as_FLUFL
doesn't work #125331