wait, since when python.org has a discuss subdomain? And it's running Discourse which is built on RoR? What the...
The Python community tends to favor pragmaticism over purity.
Python 3.12.0 is to remove long-deprecated items
221–230 of 257 posts
Re: Python 3.12.0 is to remove long-deprecated items
#222Earlier quoted context omitted.
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".
Here's an actively maintained version of Python 2:
https://www.activestate.com/products/python/python-2-7/
As you can see, it is still offered, and the PSF doesn't have a problem with that.
The problem with those other groups is that they didn't want to maintain Python 2. They wanted to take it and develop it, evolving the language separately from Python 3 - while also calling the result "Python 2.8" (and presumably later Python 2.9 etc). It stands to reason that people who own the brand don't want it to be associated with a third-party fork that's making its own major design decisions, no?
Re: Python 3.12.0 is to remove long-deprecated items
#223Earlier quoted context omitted.
> By comparison, I never experienced such churn with perl. I literally have 20+ years old perl scripts, usually doing one single thing (many of them) still working on new machines without issues. I've rewritten some stuff from python(2) to perl (instead of python3) because i was unsure when a new rewrite for whatever reasons... Now, more python stuff needs fixing, while perl still works.
Your kinda comparing simple basic api in perl vs likely more complicated python code here aren't you? If you had a set of single simple python functions maybe they wouldn't have broke as much if at all?
> If you had a set of single simple python functions maybe they wouldn't have broke as much if at all?
Like (python 2):
print "hello world!"
Re: Python 3.12.0 is to remove long-deprecated items
#224Earlier quoted context omitted.
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).
My experience with Python is probably closer to nicoco's than wakeupcall's (usually pretty painless), but I tend to prefer the Java approach. Waiting three releases for removal gives you four years of support and seven years of security fixes. That isn't unreasonable but feels a little too fast in a language as old as Python (especially with people still burned from Python 3).
Re: Python 3.12.0 is to remove long-deprecated items
#225I'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…
> By comparison, I never experienced such churn with perl. I literally have 20+ years old perl scripts, usually doing one single thing (many of them) still working on new machines without issues. I've rewritten some stuff from python(2) to perl (instead of python3) because i was unsure when a new rewrite for whatever reasons... Now, more python stuff needs fixing, while perl still works.
Somewhere Larry Wall is laughing (and/or crying.)
Re: Python 3.12.0 is to remove long-deprecated items
#226I'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…
The only language I've experienced so much churn with is Swift (which loves to break things, vs. the relative stability of Objective-C.) But Apple has already outsourced yearly iOS compatibility updates onto every developer, and now they have even decided to remove apps that haven't been updated recently from the app store. A stable game/app development platform it is not.
I am still shocked though by the Python project deciding to break billions of lines of legacy code. What other platforms demonstrate that kind of contempt for their developers?
Removing the print statement seems like a particularly negative trade-off: breaking code in the name of syntactic purity, instead of simply deprecating the print statement and letting it live on compatibly with the print() function.
Since then a bunch of new syntax (not all of which is bad) has of course been added.
It's also weird that until now they seem to have largely ignored performance and focused on adding random new features.
Re: Python 3.12.0 is to remove long-deprecated items
#227One thing that’s ticked me off is Python has been expanding the standard library.
That’s a pain when you already are using libs that imitate the “new” behavior.
Either the new tools are less good, or they destroy development in the existing tools.
Twisted was, and is, a really cool framework. Unfortunately, it’s doomed.
There were a ton of really good datetime utilities before … datetime.
Oh well. Complain complain.
Re: Python 3.12.0 is to remove long-deprecated items
#228Earlier quoted context omitted.
Your kinda comparing simple basic api in perl vs likely more complicated python code here aren't you? If you had a set of single simple python functions maybe they wouldn't have broke as much if at all?
> If you had a set of single simple python functions maybe they wouldn't have broke as much if at all? Like (python 2): print "hello world!" ? ( https://docs.python.org/2/tutorial/introduction.html )
Python 3 came out 14 years ago, and changing the syntax of one function wasn’t even a big deal then. Literally a 10 minute code search to fix a project.
It might be time to move on…
Re: Python 3.12.0 is to remove long-deprecated items
#229One thing that’s ticked me off is Python has been expanding the standard library. That’s a pain when you already are using libs that imitate the “new” behavior. Either the new tools are less good, or they destroy development in the existing tools. Twisted was, and is, a really cool framework. Unfortunately, it’s doomed. There were a ton of really good datetime utilities before … datetime. Oh well. Complain complain.
I don’t think datetime is a good example, been around for a long time. Dataclasses might be one.
Re: Python 3.12.0 is to remove long-deprecated items
#230Earlier quoted context omitted.
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!
Umm, I didn’t have a great experience with Poetry. For starters, I wanted to create a separate virtual env to install Poetry in and have Poetry install the project’s dependencies in a separate virtual env. There was simply no way to do that and I didn’t wanna install Poetry globally on my machine. I also didn’t wanna use docker just for this, so I realized that Poetry could just not be for me.