Is there any model or rationale behind introducing breaking changes in a minor release? What are the version numbers good for if not to indicate how important the changes are?
Python 3.12.0 is to remove long-deprecated items
141–150 of 257 posts
Re: Python 3.12.0 is to remove long-deprecated items
#142I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to…
This doesn't make sense. You can pin versions and it will work forever. If you want to update you need to update your code.
Not forever, eg very old versions of Python cannot install dependencies from PyPI anymore because SSL is stricter nowadays.
Re: Python 3.12.0 is to remove long-deprecated items
#143Earlier quoted context omitted.
Deprecated does not mean removed. They are still there, working fine, having no big reason to change them. I know it, as I just checked my and my workplaces code, and there are several usages of deprecated code. And we are on 3.9/3.10.
Except the notice is about "removing deprecated modules"? Deprecation usually means "These are going away at some point. Be aware.".
It should mean 'next major version'.
But the Python community fear major version changes. So the minor versions become major versions.
Re: Python 3.12.0 is to remove long-deprecated items
#144I see telnetlib is on the way out in 3.13 or so, which means a lot of pointless busywork in my future. Its a super useful module for a lot of tasks. The suggested replacements either are asyncio based (which means whole ass rewrites as asyncio is really fucking opinionated), or are excessively restrictive in some stupid way. "Infosec" at work tend to raise a ruckus when their scans detect "older" versions of Python o…
Telnet should not be used anymore. Its an old protocol, and not suitable for today especially in the case of security. You can easily migrate to ssh.
"Telnet... [is] an old protocol..."
Ok. Telnet is a protocol, it is not synonymous with TCP.
As for unencrypted traffic generally, I see no reason for fetishizing encryption. "Compute" is not synonymous with teh cloudz. Cloud tech is not synonymous with teh cloudz. It's trivial to put e.g. Nginx in front of something.
If you need encryption between 127.0.0.1 and 127.0.0.42 you clearly don't trust the hardware you're running on; I'm sure someone's got some clever way of hiding the private keys, but "clever" doesn't mean provably secure. Between containers... meh. Show me you thought about it and have a threat model.
Between datacenters... not so much. Do I care whether the connection is encrypted, or whether all traffic goes through a tunnel? I'd like to see a threat model. Is sigint included?
Even across the globe I might make an exception for a well-reasoned argument. That would almost certainly have to be data which was an observable: the time, a flow rate. Encryption is not the same as tamper-proof. Even unencrypted data might need defense against that. (Maybe secrecy is easier than nonrepudiability. Maybe.)
Secrecy is not identical to privacy. Security is not identical to either of those, and hypervigilance isn't the same as not needing to be concerned with something (these days security can be either of those). Observability might be more important than either secrecy or privacy depending on the application, and who is doing the observing.
A lot of it depends on where you demarc your rings of hell and how you defend things.
I send data in the clear sometimes and I'm ok with it. I also use a telnet client for decidedly "not telnet protocol" purposes related to diagnostics as well as observability.
Re: Python 3.12.0 is to remove long-deprecated items
#145wait, since when python.org has a discuss subdomain? And it's running Discourse which is built on RoR? What the...
Since September 2018 at least:
Re: Python 3.12.0 is to remove long-deprecated items
#146Is there any model or rationale behind introducing breaking changes in a minor release? What are the version numbers good for if not to indicate how important the changes are?
Python has never followed semver. It's saner to treat minor releases as semver-major, and patches as semver-minor.
Re: Python 3.12.0 is to remove long-deprecated items
#147Earlier quoted context omitted.
This doesn't make sense. You can pin versions and it will work forever. If you want to update you need to update your code.
Not forever, eg very old versions of Python cannot install dependencies from PyPI anymore because SSL is stricter nowadays.
I mean that level of breakage is good. You can’t keep running outdated stuff while expecting to interact with the wider world.
Re: Python 3.12.0 is to remove long-deprecated items
#148I hope we don't end up with the same things as the java world. JDK9 removed and moved to a library a few things like JAXB. Since JDK11, every new version is harsher for programs that use reflection to mess with non-published internals. Both are good changes, BTW. In theory, you add a few libs and you're ready to upgrade. In practice, adding libs at scale is hard, and quite a few dependencies of dependencies of ... ar…
> Both are good changes, BTW.
I disagree. The entire point of setAccessible is to say I want to access nonpublic things. I shouldn't have to also say "Simon says, pretty please" for each such access on the command line to be able to do so.
Re: Python 3.12.0 is to remove long-deprecated items
#149I'm curious if there's anything preventing them from switching to semver.
Their own decisions. They want to spread little breakages over many realeases instead of collecting them into big breakages, due to the 2 to 3 fiasco. Feels like an over-correction imho.
Re: Python 3.12.0 is to remove long-deprecated items
#150If we're going to be making backwards incompatible changes to unittest, it'd be nice to introduce PEP8-compatible names, deprecate the old ones, and remove then in 3.20 or something. (I know there's pytest and nosetests, but especially when teaching people, it's nice to use what's in the standard library and unittest sticks out for having things named differently)
Logging is another module that is non PEP8. Would be nice to clean there up in some point to increase consistency.
or even just getting rid of sprintf formatting.