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.
Python 3.12.0 is to remove long-deprecated items
101–110 of 257 posts
Re: Python 3.12.0 is to remove long-deprecated items
#102I 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.
Re: Python 3.12.0 is to remove long-deprecated items
#103I 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…
Re: Python 3.12.0 is to remove long-deprecated items
#104If 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)
Would be nice to clean there up in some point to increase consistency.
Re: Python 3.12.0 is to remove long-deprecated items
#105In 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
#106Great, 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
Re: Python 3.12.0 is to remove long-deprecated items
#107For 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
#108I'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…
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
#109I'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
#110I 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.