Live data from Hacker News

Python 3.12.0 is to remove long-deprecated items

discuss.python.org

101–110 of 257 posts

Re: Python 3.12.0 is to remove long-deprecated items

#101

Great, so now not only Python will be incompatible with itself, but also incompatible with itself even if you use Python 3. Sigh.

Or, the glass half full view of the world suggests that low usage high barrier to maintenance module deprecation increases overall long term improvements and compatibility at the cost of small, planned, notified, short term inconvenience.

I think you're missing the point. Nothing is wrong with deprecation, but it should be done properly. Ideally, breaking changes should correspond to a major version increase

Re: Python 3.12.0 is to remove long-deprecated items

#102

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

You should be able to repackage it as a module.

That's what I'm thinking, someone could always throw it up on pypi

Re: Python 3.12.0 is to remove long-deprecated items

#103

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

Re: Python 3.12.0 is to remove long-deprecated items

#104
post #67

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

Re: Python 3.12.0 is to remove long-deprecated items

#105
I 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 ... are using reflection to mess with internals.

As a result, there are still a lot of enterprise applications on JDK8 and JDK11, even if the security impact of this is bad and the fix should be easy.

For a typical example: see https://github.com/x-stream/xstream/issues/101

Re: Python 3.12.0 is to remove long-deprecated items

#106

Great, so now not only Python will be incompatible with itself, but also incompatible with itself even if you use Python 3. Sigh.

You should sign up to maintain those ancient modules

Several groups of people offered to maintain python 2. They were told very clearly they could not do so "officially", and we're even threatened with lawyers if their thing looked like it could be mistaken for "Python 2".

Re: Python 3.12.0 is to remove long-deprecated items

#107
I'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 swallow. The amount of small and large breakage I had ever since I started to use it for production work (v2.6 and onward) has been relentless. Small and large breakages requiring constant retooling and reworking. Minor release? Yeah, still breaks just as much as a major one. pyenv doesn't help when you dependencies need to be updated, and the updates do not support the lower versions you wanted to use anyway. Containerizing everything is a not a solution for a project is expected to be supported for years so the real way forward is to fix it, again, and again, and again. My experience is that every 6 months there _will_ be work just to fix bitrotting. A one year old python project will hardly even run unless it's using the stdlib only.

By comparison, I never experienced such churn with perl.

Re: Python 3.12.0 is to remove long-deprecated items

#108

I'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 is the top reason I chose Perl for my project.

Literally every time I try to use someone else's Python code from GitHub I run into this crap.

I wanted my project to be easy to install and run, so I chose Perl.

Re: Python 3.12.0 is to remove long-deprecated items

#109

I'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 is the top reason I chose Perl for my project. Literally every time I try to use someone else's Python code from GitHub I run into this crap. I wanted my project to be easy to install and run, so I chose Perl.

I have had Perl scripts which I've not used for 15 years, run them expecting to need to fix something, but nothing needed ...

Re: Python 3.12.0 is to remove long-deprecated items

#110

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

Part of security is acknowledging that business needs can't always fit in rigid ideals and coming up with compensating controls.
Post reply on HN