Skip to content

from __future__ import barry_as_FLUFL doesn't work #125331

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

Closed
JelleZijlstra opened this issue Oct 11, 2024 · 12 comments
Closed

from __future__ import barry_as_FLUFL doesn't work #125331

JelleZijlstra opened this issue Oct 11, 2024 · 12 comments
Labels
topic-parser type-bug An unexpected behavior, bug, or error

Comments

@JelleZijlstra
Copy link
Member

JelleZijlstra commented Oct 11, 2024

Bug report

Bug description:

% ./python.exe -c 'from __future__ import barry_as_FLUFL; print(1 <> 2)'
  File "<string>", line 1
    from __future__ import barry_as_FLUFL; print(1 <> 2)
                                                   ^^
SyntaxError: invalid syntax

But with Barry as the FLUFL, <> is the correct way to test for inequality.

The future works only if you pass the right flag to compile() (as test_flufl.py does), but there's no way to do that in a file.

Obviously this future is a joke so this doesn't matter greatly, but I think it indicates that future imports that affect the parser aren't handled properly. That's something we should fix in case we get other futures in the ... future that also affect the parser. The joke future is also useful as a way to demonstrate how future statements work in general without having to rely on a specific future that will go away in a few releases.

CPython versions tested on:

3.12, CPython main branch

Operating systems tested on:

No response

Linked PRs

@nineteendo
Copy link
Contributor

We would have to be careful to make sure that this easter egg can't be used in production...

@Wulian233
Copy link
Contributor

This issue was discussed recently, and IDLE is not a bug
#124999 (comment)

#124999 (comment)

@ZeroIntensity
Copy link
Member

Clearly this should be a blocker for all upcoming releases 😄

@pablogsal
Copy link
Member

I'm investigating and working on a possible fix. I am not fully convinced that is a but but I agree it looks like one.

@pablogsal
Copy link
Member

Obviously this future is a joke so this doesn't matter greatly, but I think it indicates that future imports that affect the parser aren't handled properly.

Not really: the parser receives all its configuration when executed, including the flags. The parser cannot change the configuration mid execution (among other things because it doesn't "know" what an import is supposed to do).

That's something we should fix in case we get other futures in the ... future that also affect the parser.

The way most futures work is by changing the compiler, not the parser. This is the exception and in reality is not even an exception because the way this was added was to only work in interactive mode. Indeed if you try this in a file:

from __future__ import barry_as_FLUFL
1 <> 2

it won't work:

 File "/home/pablogsal/github/python/main/lol.py", line 2
    1 <> 2
      ^^
SyntaxError: invalid syntax

Is only prepared to work on sequential-execution where the previous statement modifies the flags. That's why it works in the REPL:

>>> from __future__ import barry_as_FLUFL
>>>
>>> 1 <> 2
True

this is because when executing the first statement, the second call to parse changed flags. But this only happened after it was executed (not parsed).

@pablogsal
Copy link
Member

The toll to fix this is not trivial: every call to parse/compile would need to be actually 2 calls to parse/compile OR we need to teach the parser to change flags mid run (which is not trivial because future imports have certain restrictions):

1 != 2
from __future__ import barry_as_FLUFL

gives:

  File "/home/pablogsal/github/python/main/lol.py", line 2
    from __future__ import barry_as_FLUFL
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: from __future__ imports must occur at the beginning of the file

and these restrictions are not checked by the parser but the compiler (in the symbol table):

check_import_from(struct symtable *st, stmt_ty s)

@pablogsal
Copy link
Member

I think that given that this will introduce some slowness to fix or maintenance burden in the parser and this was the way this worked since it was introduced I suggest to close as not a bug.

@JelleZijlstra
Copy link
Member Author

The Python 2-era future imports that changed the parser did work this way:

$ python2.7 -c 'from __future__ import print_function; print 42'
  File "<string>", line 1
    from __future__ import print_function; print 42
                                                  ^
SyntaxError: invalid syntax
$ python2.7 -c 'from __future__ import print_function; print(42)'
42

But you're right that more recent future imports have been implemented in the compiler, not the parser, and I believe you that it's difficult to implement this as desired in the parser. Still would be nice to make this work, but probably not worth it until we have a non-joke future import that needs it.

@pablogsal
Copy link
Member

pablogsal commented Oct 14, 2024

The Python 2-era future imports that changed the parser did work this way:

Yeah it was basically in a function called future_hack, that tells you everything you need to know to know about the maintenance effect :)

@pablogsal pablogsal closed this as not planned Won't fix, can't repro, duplicate, stale Oct 14, 2024
@pablogsal pablogsal reopened this Oct 14, 2024
@pablogsal
Copy link
Member

pablogsal commented Oct 14, 2024

Ok I have a future_hack PEG edition:

#125482

We could go with this now if @lysnikolaou doesn't find it too gross. This is relying on the fact that if one of these nodes gets successfully parsed the backtrack will not change its meaning (which is sort of gross).

@thatbirdguythatuknownot
Copy link
Contributor

I wanted to make this issue along with the other barry_as_FLUFL issue I found a few months ago but I thought it would get shut down immediately :p

@wimglenn
Copy link
Contributor

wimglenn commented Dec 9, 2024

Coincidentally, I asked similar on stack overflow back in Sept- https://stackoverflow.com/q/79004026/674039

Nobody was able to answer it there (yet), but Pablo's comments here effectively answer the question.

@pablogsal pablogsal reopened this Mar 10, 2025
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Mar 10, 2025
…ly (pythonGH-125482)

(cherry picked from commit 3bd3e09)

Co-authored-by: Pablo Galindo Salgado <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Mar 10, 2025
…ly (pythonGH-125482)

(cherry picked from commit 3bd3e09)

Co-authored-by: Pablo Galindo Salgado <[email protected]>
pablogsal added a commit that referenced this issue Mar 10, 2025
…fly (GH-125482) (#131063)

gh-125331: Allow the parser to activate future imports on the fly (GH-125482)
(cherry picked from commit 3bd3e09)

Co-authored-by: Pablo Galindo Salgado <[email protected]>
pablogsal added a commit that referenced this issue Mar 10, 2025
…fly (GH-125482) (#131062)

gh-125331: Allow the parser to activate future imports on the fly (GH-125482)
(cherry picked from commit 3bd3e09)

Co-authored-by: Pablo Galindo Salgado <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-parser type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

7 participants