Python 3.14.0 released
Posted Oct 7, 2025 19:20 UTC (Tue)
by mmm (subscriber, #155993)
[Link] (1 responses)
Posted Oct 8, 2025 10:24 UTC (Wed)
by nowster (subscriber, #67)
[Link]
Posted Oct 8, 2025 7:28 UTC (Wed)
by fishface60 (subscriber, #88700)
[Link] (5 responses)
I use it a lot so am surprised to see it labelled problematic enough for eventual removal without replacement.
Posted Oct 8, 2025 12:18 UTC (Wed)
by randomguy3 (subscriber, #71063)
[Link] (4 responses)
Posted Oct 8, 2025 13:12 UTC (Wed)
by fishface60 (subscriber, #88700)
[Link] (3 responses)
but I can understand the logic for soft-deprecating just in documentation before scheduling removal if you know there's a problem and just haven't settled on the solution yet.
Posted Oct 8, 2025 17:22 UTC (Wed)
by meejah (subscriber, #162580)
[Link] (1 responses)
Posted Oct 9, 2025 8:01 UTC (Thu)
by fishface60 (subscriber, #88700)
[Link]
Joking aside, batteries included is a great strength for python and it wouldn't be half as versatile for scripting if everything had to install dependencies.
Also my current work's constraints effectively limit me to stdlib only for most of the code, so healthy batteries are in my interests.
I've been meaning to give Tap a try to push the type checking boundary as far as the CLI args though, so perhaps I'll have the opportunity in a future project.
Posted Oct 9, 2025 21:56 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
* A function, acceptable to add_argument's type parameter, that either returns a pathlib.Path, or some sentinel value (such as None) to indicate that we should use stdin/out.
Fortunately, these are not terribly difficult to write by hand.
Posted Oct 9, 2025 6:32 UTC (Thu)
by callegar (guest, #16148)
[Link] (2 responses)
Posted Oct 9, 2025 11:15 UTC (Thu)
by callegar (guest, #16148)
[Link] (1 responses)
Posted Oct 10, 2025 1:59 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Pi-thon
Famously TEX is known for having version numbers which asymptotically approach π.
Pi-thon
Surprising deprecation
If you're interested, there is extensive discussion on the linked github issue, but essentially the conclusion was that its presence in the stdlib encourages idioms that lead to bad resource management and unexpected behaviour (like clobbering files even when argparse fails to finish parsing arguments).
Surprising deprecation
Surprising deprecation
Surprising deprecation
Surprising deprecation
Surprising deprecation
* A function that accepts the return value of the first function plus the usual other open() arguments, and either returns Path.open(...), or one of sys.std{in,out}{,.buffer} as indicated by the mode (possibly wrapped in some gunk that makes it behave properly in a with statement, without accidentally closing stdout or some such nonsense).
Anyone knows if Spyder can be used with this Python version or if some of its deps are unavailable with it?
Spyder?
Answering my own question, just in case someone can find this useful. No spyder yet on Python 3.14, due to its dependency jellyfish not being available for this Python version. This is making me curious. It is the first time that I encounter a new Python release (not jumping from Python 2 to Python 3 of course), breaking a recent package (jellyfish last release is from in March). Wonder if it was jellifish not to follow deprecation indications, or if something else happened.
Spyder?
Spyder?