Repository navigation
Support pythonπ in Python 3.14 venv's #119535
Description
Activity
- added a commit that references this issue
on May 25, 2024 I guess I'm too boring, but I'm -1 on this. This would a nice-ish easter egg, but we'd have to revert for 3.15 and that opens up backward compatibility issues.
Reacted by Joshua Herman, dsg, Serhii Khalymon, Miro Hrončok, Andras Deak, powercoconola, Mali Gaurav Sambhaji and Marek MadejskiReacted by Sebastian, Nate Harris and danielchimReacted by Danila Mikhaltsov, roundabout-host.com, Alex Waygood, Thomas Grainger, Roman Solomatin, Fedor Eremeev, Nice Zombies, Kirill Podoprigora, Mihail Shapovalov, Ilya Siamionau and 14 more+1 It doesn't need to be reverted. We check specifically for 3.14.Reacted by Sebastian and cogphnI have seen cute things like this break systems . I believe racket-lang had some birthday code trigger but then it broke the system on that day. Who knows what this would break and it seems too hard to test.
+1 It doesn't need to be reverted. We check specifically for 3.14.
Still, someone might start using pythonπ in a shell script with 3.14 and then gets a broken script once upgrading to 3.15 because pythonπ doesn't exist there. That's not a very likely scenario, but still.
And yes, this would have to be reverted in 3.15 because otherwise we'd end up with dead code in the stdlib.
Unlike most easter eggs, this will be directly presented to users because it will appear in tab completion, so you will get questions about it. Users without Unicode fonts in their terminal will be extra confused. I don't think it is worth the support burden.
Reacted by Joshua Herman, Andras Deak, Igor Khrol, Johann Christensen, powercoconola, HoloTheDrunk, marnitto, py660 and Seth R. JohnsonReacted by Nate HarrisI agree with @ronaldoussoren. But, I still advocate for using
pieaster egg for 3.14 release somewhere else.Reacted by Nice Zombies, Stanislav Zmiev, Pepelulka, Sergey B Kirpichev, beskep, powercoconola and py660Still, someone might start using pythonπ in a shell script with 3.14 and then gets a broken script once upgrading to 3.15
The same argument would apply to using "python3.14" in a shell script
Not wanting easter eggs is a valid personal difference, they are sometimes contentious (even if the CPython project has a history of a few). I think as far as they go, this one is predictable and harmless. I do concede that in 3.15 it would create two dead lines of code (since it's version gated, fully dead, no deadline to revert) — to me that's a reasonable cost for a little bit of joy.
I've heard some FUD about the use of a Greek character. It's 2024, I'm genuinely curious, does anyone have an example of a platform/filesystem we support that this would cause a real issue on? (π is not that special, it's fully normalised Unicode. I couldn't find problems when looking into it, also note the change is restricted to
os.name == "posix"). Note also that PEP 11 has this to say https://peps.python.org/pep-0011/#legacy-c-localeReacted by Adam Turner, Alex Waygood, Evgenii Zheltonozhskii, Brent Lidstone, Bill and 27Onion NebellReacted by Joshua HermanBut, I still advocate for using pi easter egg for 3.14 release somewhere else.
Minor releases 3.14.1, 3.14.15, 3.14.159, ... (or rather 3.14.2, 3.14.16, 3.14.159...)? But
SimpsonsTeX already did it!Reacted by sobolevn, Nice Zombies, Shantanu, Evgenii Zheltonozhskii, beskep, Huu Hai and JohnReacted by Sergei Beilin, Inada Naoki and Luis Castro Martínin 3.15 it would create two dead lines of code
Technically we could wait with merging this until a 3.14 branch is created, right? Then there's no need to revert it.Minor releases 3.14.1, 3.14.15, 3.14.159, ...
How about displaying 3.14.2, 3.14.3, ... as 3.14.15, 3.14.159... in the REPL? Because I'm afraid
PY_VERSION_HEXmight make things difficult.easter eggs do create maintenance costs and bugs
The chance at bugs should be lower since it's just for one release (and not as complicated as
<>).displaying ... in the REPL?
Well, with something like ~20 minor releases this will be
>>> "3.14."+f"{gmpy2.const_pi():.22f}"[4:] '3.14.15926535897932384626'
On another hand, current 1st line of the banner doesn't fit common default of 80 characters width anyway... ;)
I'm afraid PY_VERSION_HEX might make things difficult.
Yeah, and rather impossible. 159 will be the last minor version, that increases monotonically and don't mess with major or minor version.
Reacted by Nice Zombies, Inada Naoki and Wulian233we could wait with merging this until a 3.14 branch is created
Whilst this is technically possible, our development process uses a backport workflow apart from exceptional cases. More importantly, 3.14 will be branched at beta 1, where no new features are allowed. So it would need to be merged now.
a reasonable cost for a little bit of joy.
I concur. This is a bit of fun, easily noticable, and a tongue-in-cheek reference to the "pi" release of Python. Remember that the language itself is named after a fairly irreverent programme!
A
Reacted by Alex Waygood, Sam James, Shantanu, Huu Hai and Barrett Ray2 remaining items
Merged.
Now, everyone: shhh!
Reacted by powercoconolaReacted by Miro Hrončok, bluss, Wulian233, Adam Johnson, Lucero Alvarado Ruiz (Lu0), Huu Hai, Alisa Sireneva, Agriya Khetarpal, Connor Ward, David Racovan and 7 moreReacted by martín, Heyner Cuevas, Bartosz Sławecki, Wulian233, Agriya Khetarpal, QuazarOmega and kieraI'll be that annoying guy now:
𝜋thonlooks and sounds way cooler and I'm going to open a PR 👻Reacted by Sam James, Wulian233, Kent Matsuura, Nikita Sheverdov, Huu Hai, Subhayu Kumar Bala, David Dzhalaev, Henrique Pickler, Agriya Khetarpal, baseplate-admin and 13 moreReacted by QuazarOmega- added a commit that references this issue
on Oct 15, 2024 - added a commit that references this issue
on May 15, 2025 pyτhonwould be twice as goodReacted by Hugo van Kemenade, QuazarOmega, aiudirog and 27Onion NebellReacted by Evgenii Zheltonozhskii, Nice Zombies and aiudirogI have seen cute things like this break systems . I believe racket-lang had some birthday code trigger but then it broke the system on that day. Who knows what this would break and it seems too hard to test.
FWIW, it did break things for me. There are some (edge cases) where various tools don't like non-ASCII path names. This is arguably a bug in those tools ( ostreedev/ostree#3431 ). Perhaps exposing these issues is a good thing.
Reacted by foreignmelomanYes, good to see the maintainer of libostree sees ASCII-only paths is not enough and is working on a PR to add UTF-8 support 👍
Reacted by Shantanu and foreignmelomanFWIW, it did break things for me. There are some (edge cases) where various tools don't like non-ASCII path names. This is arguably a bug in those tools ( ostreedev/ostree#3431 ). Perhaps exposing these issues is a good thing.
Note that some tools intentionally reject all non-ASCII characters because of the (sometimes severe) risks of dealing with them. Unicode parser vulnerabilities is an obvious case, but Trojan Source attacks are also a thing, as are mismatches between Unicode versions supported by various tools. In particular, Kicksecure has a handler for the
org.freedesktop.FileManager1D-Bus interface that will scream very loudly if it detects non-ASCII in filenames as a security precaution. (It also comes with lots of fancy tools for inspecting those characters without displaying them raw, since displaying them raw opens the Trojan Source hole and potentially other unknown Unicode what-you-see-is-not-what's-actually-there bugs.)Also, some snaps in Ubuntu are struggling with this "feature" causing lovely directory listings like:
# ls -lh prime/bin/ .... -rwxr-xr-x 3 root root 225 Sep 17 00:08 pip -rwxr-xr-x 3 root root 225 Sep 17 00:08 pip3 -rwxr-xr-x 3 root root 225 Sep 17 00:08 pip3.14 lrwxrwxrwx 1 root root 7 Sep 17 00:08 python -> python3 lrwxrwxrwx 1 root root 21 Sep 17 00:08 python3 -> ../usr/bin/python3.14 lrwxrwxrwx 1 root root 7 Sep 17 00:08 python3.14 -> python3 -rwxr-xr-x 3 root root 215 Sep 17 00:08 uvicorn lrwxrwxrwx 1 root root 7 Sep 17 00:08 ''$'\360\235\234\213''thon' -> python3Easter eggs that trigger during normal user interaction cause real-world problems virtually always. A program's behavior in response to certain input is essentially part of that program's API, and triggering an easter egg effectively changes the program's API in an unexpected and sometimes unpredictable way. The gimme gimme gimme easter egg in
manis one particularly fun example. IMO such easter eggs do not belong in critical infrastructure like Python. If there are going to be any easter eggs in any program, but especially one of this scale, they should only be able to be triggered intentionally by a user who knows or suspects they are there, like theaptitude [-vvvvvv] mooseries of jokes.Is
𝜋thonactually causing you an issue here?If so, good news! Python 3.15 is out in 9 days which removes it! 🚀
Trojan Source is an "attack is to use control characters embedded in comments and strings to reorder source code characters in a way that changes its logic". It's an attack on code review, not file systems. This pi symbol is an ordinary display character, with no BIDI direction control. It's a hard-coded constant, not attacker-controlled source code, so Trojan Source doesn't apply here.
It looks like Kicksecure only warns for non-ASCII directories, and not files like this one:
This shim displays a confirmation window for every request an application makes to open one or more directories, while also ensuring applications can only try to open directories (not files), and cannot try to open directories that the user cannot access.
The file is only created in non-Windows venvs, and only when the file system encoding is UTF-8. For "broken"
ls, this is cosmetic, I suggest setting a UTF-8 locale rather than plainC/POSIX.Reacted by ShantanuThe file is only created in non-Windows venvs, and only when the file system encoding is UTF-8. For "broken" ls, this is cosmetic, I suggest setting a UTF-8 locale rather than plain C/POSIX.
That's a good idea, will forward it to the person who originally showed me the dir listing issue.
On the Trojan Source point, filenames are a part of code review too. Unicode has more dangers than just Trojan Source attacks, and while it is possible and potentially reasonable to try to disallow / specially handle just the "bad" parts of Unicode, Unicode is so complex that some tools intentionally say "let's not even go there" for the sake of avoiding the security footguns of dealing with it. Those tools can choke on things like this. (I had forgotten that the shim mentioned only looks at directory names, which is a bit ironic because I wrote the shim, so I guess that wasn't the best example.)
If so, good news! Python 3.15 is out in 9 days which removes it! 🚀
Unfortunately Ubuntu 26.04 LTS managed to snag Python 3.14, meaning that this easter egg will probably be floating around in the wild causing weird issues in strange edge cases for at least another 9 years and 9 months.
Feature or enhancement
Proposal:
Linked PRs