Surprising deprecation

Posted Oct 8, 2025 7:28 UTC (Wed) by fishface60 (subscriber, #88700)
Parent article: Python 3.14.0 released

I was surprised to see in the extended release notes that they're deprecating argparse.FileType.

I use it a lot so am surprised to see it labelled problematic enough for eventual removal without replacement.

Surprising deprecation

Posted Oct 8, 2025 12:18 UTC (Wed) by randomguy3 (subscriber, #71063) [Link] (4 responses)

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

Posted Oct 8, 2025 13:12 UTC (Wed) by fishface60 (subscriber, #88700) [Link] (3 responses)

Thanks for the link. It's a shame not to have the proposed context managers to replace it or explicit guidance in the docs for what to do instead,

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.

Surprising deprecation

Posted Oct 8, 2025 17:22 UTC (Wed) by meejah (subscriber, #162580) [Link] (1 responses)

I recommend using Click instead of argparse.

Surprising deprecation

Posted Oct 9, 2025 8:01 UTC (Thu) by fishface60 (subscriber, #88700) [Link]

I recommend gathering requirements before making recommendations 😛

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.

Surprising deprecation

Posted Oct 9, 2025 21:56 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

IMHO the best API is probably shaped like the following:

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

Fortunately, these are not terribly difficult to write by hand.