Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.12.0 is to remove long-deprecated items

discuss.python.org

Post reply on HN
Print view View original

191–200 of 257 posts

Re: Python 3.12.0 is to remove long-deprecated items

#191

Post by josephcsible »

hyperman1 wrote: post #184
josephcsible wrote: post #148

Earlier quoted context omitted.

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

Marking random hidden internals accessible doesn't mean a private API becomes public. setAccessible is a useful tool for debug access, or for when an annotation gives extra guarantees, or you can use it on code you have access to. But you can't expect from your API vendor that they won't ever again change the internals of the implementation just because you forced your way in and monkeyed with the internals. Writing…

Those are all good reasons to not want to use setAccessible, but they're not good reasons to be unable to do so.

Re: Python 3.12.0 is to remove long-deprecated items

#192

Post by Alex3917 »

nicoco wrote: post #135
wakeupcall wrote: post #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…

For a different perspective, I started using python about 5 years ago, and I never experienced a single breakage due to a new python release. Instead, I'm always excited to read new version releases notes and it's the only thing that may make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can't wait. Removing deprecated stuff is……

Same here. I don't think I've been affected by a single deprecation since upgrading to Python3 in 2015, and even that upgrade wasn't that difficult -- mainly I was just forced to fix a few things I had been doing incorrectly, which imho is a good thing.

Re: Python 3.12.0 is to remove long-deprecated items

#193

Post by cogman10 »

nicoco wrote: post #135
wakeupcall wrote: post #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…

For a different perspective, I started using python about 5 years ago, and I never experienced a single breakage due to a new python release. Instead, I'm always excited to read new version releases notes and it's the only thing that may make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can't wait. Removing deprecated stuff is……

> Removing deprecated stuff is… the point of deprecating stuff?

The point of deprecating stuff is to redirect to newer/better/saner APIs, not necessarily removing the thing.

This is where I like Java's approach. Stuff is deprecated in the JDK but fairly rarely is it removed. When it is, it's because the feature is either unused or so detrimental to the ecosystem as to warrant removal (see: finalizers).

Re: Python 3.12.0 is to remove long-deprecated items

#194

Post by worldsavior »

masklinn wrote: post #153
worldsavior wrote: post #134

Earlier quoted context omitted.

Didn't talk about old devices. Security can be very important in cases of connecting to other servers.

> Didn't talk about old devices. Does not matter, you stated without nuance that telnet should no be used. So you told GP that they should trash their telnet-only devices.

No. You understood the phrase incorrectly and assume I mean "bang the head against the wall and don't you telnet". Of course if you have no other choice, go for it. But if you do...

Re: Python 3.12.0 is to remove long-deprecated items

#195

Post by worldsavior »

m3047 wrote: post #144
worldsavior wrote: post #103

Earlier quoted context omitted.

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…

I dont see why a thread model is needed here, encryption is always important, especially in big corps. It seems like you're stating that a normal person doesnt need security.

Re: Python 3.12.0 is to remove long-deprecated items

#196

Post by smeagull »

wakeupcall wrote: post #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…

I missing print without parentheses.

Re: Python 3.12.0 is to remove long-deprecated items

#197

Post by worldsavior »

an-unknown wrote: post #137
worldsavior wrote: post #127

Earlier quoted context omitted.

Telnet does not have any standard security, at least by default. No encryption and no authentication among others.

This is factually wrong. There are even multiple different authentication and encryption schemes defined for telnet, see e.g.: https://www.iana.org/assignments/telnet-options/telnet-optio... Just because some old and rudimentary telnetd or telnet client doesn't implement it doesn't mean it doesn't exist / isn't used.

Those are data formats, and a client is needed to support those (on both endpoints). You better just use something modern like ssh instead of hunting for clients (and making sure they're reliable).

Re: Python 3.12.0 is to remove long-deprecated items

#198

Post by chaxor »

skullone wrote: post #123
driverdan wrote: post #115

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

Yah, nothing the GP says makes any sense. I've been working with large code bases with many languages for many years. None are perfect, but the GP makes no sense, sounds like poor decisions or poor code rather than a poor language.

The idea that pinning versions and using environments will make your code run stable forever is very wrong (in python). You can't even get things to run for a few years this way. Many of the packages are simply not available anymore. Ever tried to get an environment running that uses qt4 on py2.7? It really wasn't that long ago that py2.7 was standard (in the stable code realm that we're talking about).

Re: Python 3.12.0 is to remove long-deprecated items

#199

Post by nomel »

davidktr wrote: post #190
rochak wrote: post #171

Earlier quoted context omitted.

Except for when it comes to packaging and distribution. That is still a nightmare for newbies.

Agreed, but Poetry works wonderfully if the features are sufficient for your use case.

Sure, but wait until you see what next year brings us!

Re: Python 3.12.0 is to remove long-deprecated items

#200

Post by chaxor »

wakeupcall wrote: post #112
forgotmypw17 wrote: post #108

Earlier quoted context omitted.

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.

It's a real shame, since this is a project management issue. You'd expect python to be a stable language given its age. I expected that to be the case at 2.7. Then at 3.1. At 3.12 it's still not the case. It's reasonable to expect this is not going to change.

It's gotten far, FAR worse since Guido stopped having as much guidance. The increase in mandatory updates at regular intervals is a recipe for disaster in most cases, as it is in python.

Also, to pile on top of the stdlib problems - it's probably clear to most everyone at this point - but NVIDIA and Google (tensorflow) are really some of the biggest reasons python sucks in this way. They're the ones that cause most of the breakage. Starting with Nvidia making breaking changes, which then propagates to tensorflow et al, and then to enormous number of packages that depend on these fundamental packages.

So to summarize, it's mostly Nvidia's fault.

Post reply on HN