Support `pythonπ` in Python 3.14 venv's

[hauntsaninja]

Feature or enhancement

Proposal:

λ env/bin/pythonπ
Python 3.14.0a0 (heads/main-dirty:de19694cfb, May 24 2024, 23:13:56) [Clang 15.0.0 (clang-1500.3.9.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Linked PRs

• gh-119535: python𝜋 #119536
• gh-119535: Support 𝜋thon in Python 3.14 venvs #125035

[ronaldoussoren]

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.

[nineteendo]

+1 It doesn't need to be reverted. We check specifically for 3.14.

[zitterbewegung]

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

[ronaldoussoren]

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

[jbosboom]

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.

[sobolevn]

I agree with @ronaldoussoren. But, I still advocate for using pi easter egg for 3.14 release somewhere else.

[hauntsaninja]

Still, 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-locale

[skirpichev]

But, 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!

[sobolevn]

Proof that easter eggs do create maintenance costs and bugs: #124960

[nineteendo]

in 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_HEX might 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 <>).

[skirpichev]

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.