GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — `from __future__ import barry_as_FLUFL` doesn't work · Issue #125331 · python/cpython

from __future__ import barry_as_FLUFL doesn't work #125331

New issue
Copy link
New issue
Copy link
Closed
Closed
from __future__ import barry_as_FLUFL doesn't work#125331
Copy link
Labels
topic-parsertype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@JelleZijlstra
JelleZijlstra
opened on Oct 11, 2024
Issue body actions

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

  • gh-125331: Allow the parser to activate future imports on the fly #125482
  • [3.13] gh-125331: Allow the parser to activate future imports on the fly (GH-125482) #131062
  • [3.12] gh-125331: Allow the parser to activate future imports on the fly (GH-125482) #131063
Reacted by Wim Jeantine-Glenn and Wulian233
Reacted by Jacob Coffee, Peter Bierma and sobolevn

Activity

  1. JelleZijlstra
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    topic-parser
    on Oct 11, 2024
  2. nineteendo commented on Oct 11, 2024

    @nineteendo
    nineteendo
    on Oct 11, 2024
    Contributor
    More actions

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

  3. Wulian233 commented on Oct 11, 2024

    @Wulian233
    Wulian233
    on Oct 11, 2024
    Contributor
    More actions

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

    #124999 (comment)

  4. ZeroIntensity commented on Oct 12, 2024

    @ZeroIntensity
    ZeroIntensity
    on Oct 12, 2024
    Member
    More actions

    Clearly this should be a blocker for all upcoming releases 😄

    Reacted by Nice Zombies
  5. pablogsal commented on Oct 14, 2024

    @pablogsal
    pablogsal
    on Oct 14, 2024
    Member
    More actions

    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.

    Reacted by Jelle Zijlstra, Nice Zombies and Peter Bierma
  6. pablogsal commented on Oct 14, 2024

    @pablogsal
    pablogsal
    on Oct 14, 2024
    Member
    More actions

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

  7. pablogsal commented on Oct 14, 2024

    @pablogsal
    pablogsal
    on Oct 14, 2024
    Member
    More actions

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

    cpython/Python/symtable.c

    Line 1777 in 843d28f

    check_import_from(struct symtable *st, stmt_ty s)

  8. pablogsal commented on Oct 14, 2024

    @pablogsal
    pablogsal
    on Oct 14, 2024
    Member
    More actions

    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.

  9. JelleZijlstra commented on Oct 14, 2024

    @JelleZijlstra
    JelleZijlstra
    on Oct 14, 2024
    MemberAuthor
    More actions

    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.

  10. pablogsal commented on Oct 14, 2024

    @pablogsal
    pablogsal
    on Oct 14, 2024
    Member
    More actions

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

    Reacted by Jelle Zijlstra, Nice Zombies and Wim Jeantine-Glenn
  11. pablogsal
    closed this as not plannedon Oct 14, 2024
  12. pablogsal
    reopened this on Oct 14, 2024
  13. pablogsal
    added a commit that references this issue on Oct 14, 2024

    pythongh-125331: Allow the parser to activate future imports on the fly

    63640cc
  14. pablogsal commented on Oct 14, 2024

    @pablogsal
    pablogsal
    on Oct 14, 2024
    Member
    More actions

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

  15. thatbirdguythatuknownot commented on Oct 15, 2024

    @thatbirdguythatuknownot
    thatbirdguythatuknownot
    on Oct 15, 2024
    Contributor
    More actions

    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

  16. wimglenn commented on Dec 9, 2024

    @wimglenn
    wimglenn
    on Dec 9, 2024
    Contributor
    More actions

    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.

  17. pablogsal
    added 2 commits that reference this issue on Feb 13, 2025

    pythongh-125331: Allow the parser to activate future imports on the fly

    366f205

    gh-125331: Allow the parser to activate future imports on the fly (#1…

    3bd3e09
  18. pablogsal
    closed this as completedon Mar 10, 2025
  19. pablogsal
    reopened this on Mar 10, 2025
  20. miss-islington
    added 2 commits that reference this issue on Mar 10, 2025

    pythongh-125331: Allow the parser to activate future imports on the f…

    98f0c71

    pythongh-125331: Allow the parser to activate future imports on the f…

    f0889aa
  21. pablogsal
    closed this as completedon Mar 10, 2025
  22. pablogsal
    added 2 commits that reference this issue on Mar 10, 2025

    [3.12] gh-125331: Allow the parser to activate future imports on the …

    fcf1f57

    [3.13] gh-125331: Allow the parser to activate future imports on the …

    ebd2ed7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic-parsertype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.