Hacker News Reader

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… the point of deprecating stuff?

You should also look into pyenv if you'd like to install newer versions sooner, outside a container.

I moved to nixpkgs from pyenv about a year ago, with positive results. I think it's worth the initial effort.

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.

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

conda create -n yourenv python=3. 12 ;)

5 years is not enough to be experiencing this. The pain is very real and consumes a tremendous amount of effort. I've started writing tools just to create inventories of which packages with which versions I'm using where in order to try to automate the upgrading of virtual environments as much as possible. It's a horrible experience.

The biggest boulder I currently see rolling towards me is the MongoDB driver since I need to upgrade the databases and the drivers can't cope with the latest version.

We have recognised this problem and to that end we have produced a Stable API standard https://www.mongodb.com/docs/manual/reference/stable-api/

I realise this doesn't help you with historical API changes.

If you look for help in the MongoDB community and tag me (Joe.Drumgoole@mongodb.com) I will make sure you get help migrating your app.

https://www.mongodb.com/community/forums/

Other than the 2 to 3 transition, doesn't jive with my experience as a developer who's used Python in various projects for over 20 years (since the 1.5.2 days).

I've dealt with a lot of sideways yak-shaving work in my career and still frequently today and Python has been the absolute least of it.

Can you detail any of these "small and large breakages" or "bit rot"? It just doesn't jive with my experiences with any large code bases in nearly any language, python included.

Python 3.10 introduced asyncio changes that broke compatibility with earlier 3.x releases. I don't have the details at hand, but as I recall, some code that supported caller-supplied event loops not only broke, but could no longer be made compatible with both old 3.x and new 3.x python versions (unless separate code paths were maintained).

This was frustrating, because I don't expect point-releases to break the standard library, let alone require a code fork to maintain cross-distro compatibility. It was disappointing, because I had never encountered such breakage from python while Guido was still in charge.

I had the same experience. I was pretty annoyed to see that some server apps were unable to run after the upgrade because of some changes to the loop. "Why?", I was asking myself.

> 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!"

?

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

It was literally months to fix every change in every project and to fix all the issues coming from that. ("print" wasn't the only change in 2->3)

Our codebase is was (and is) old, but the forced change came recently, when ubuntu decided to remove python 2 support (ubuntu 20.04?). And when ubuntu decides that they want python >=3.12 as the only version installed, this means another change and more work to fix stuff that worked just fine.

Somewhere Larry Wall is laughing (and/or crying.)

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

The really nice part of sticking with python2 is that it is now a a stable interface. just like perl 5.

only half joking.

I would consider it, except it is no longer being installed most places, since it is "deprecated".

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.

I think with backwards compatibility it's "fool me once".

In order to make the most of Lindy Effect, I avoid any dependencies with less than 20 years of backwards compatibility.

For some that means a subset of features. For some like Python it means any python scripts must be optional and have Perl duplicates.

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.

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

If you want a long term snapshot of other people's packages, the onus is on you to store them indefinitely. Packages can be pinned and installed from a local folder.

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.

Okay, then practically you can't pin versions and have it work forever.

PyPI is not required to run Python though. You could serve or source those packages elsewhere. Pinning the dependencies would at least resolve compatibility of the actual code.

You can. Package everything you need with the environment and you’re done. Now whether future versions of whatever container you choose to run it in will support establishing the environment is a separate detail. There is no answer. You can go all the way to reserving an entire computer to run mission critical code but you don’t know if it is future proof in terms of electrical specifications.

That’s the point of civilization though. You iterate and what works out, other people copy and iterate even more.

> You can go all the way to reserving an entire computer to run mission critical code but you don’t know if it is future proof in terms of electrical specifications.

See, that's a beautiful example, just not in the direction that I think you intend it. I can, in fact, take an appliance that's a few decades old and plug it into a modern outlet and it'll work just fine. I do not, in fact, have to preserve an entire electrical grid just to run my application^w appliance, because the underlying infrastructure maintains compatibility.

No it is an example exactly in the incorrect way that you took it. Just because electricity has been relatively constant in specification doesn’t mean it’ll always be the case. You can work with that assumption up to even a third or fourth order approximation. But on some level it’ll fail.

Which brings you to the larger generalization that you haven’t grasped: the further down the stack you go, the more stable it is. Python is nearest the top layer. Hardware changes in decade cycles. Electricity likely in century cycles. Keep going. The laws of physics change never. Obv the time scales aren’t strictly logarithmic. Human ingenuity means we could find some exceptional electricity specification tomorrow and convert the whole world in one decade. But it is relatively rarer.

A problem with pinning is that it doesn’t only freeze features, ensuring that the features you need will be available forever, but also bugs, in particular security bugs, ensuring that security bugs you have today, but that you and possibly even the entire world are unaware of, will stay around forever.

> By comparison, I never experienced such churn with perl.

Ah, but that's because the Perl community rejected the one major attempt at such a change (Perl 6) so hard that it became its own separate language.

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.

I missing print without parentheses.

Me three, oops, meant two (extra parentheses to type). Not /s, but ;)

I’ve had that problem with Perl, too, so I think it’s more about which set of third-party packages you depend on and the norms in that space. One interesting tradeoff is that Python’s standard library is pretty large so you have a fair number of programs which can be frictionless by sticking to the stdlib.

Agree.

This is perfectly exemplified by Python 3's insistence that you call print with parenthesis:

>>> print "hello"

SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?

I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes off feeling needlessly pedantic for the language.

I disagree strongly with this take and it seems basically to be saying "better error messages are bad."

What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?

> I disagree strongly with this take and it seems basically to be saying "better error messages are bad."

I rather have something like this:

> Use exit() or Ctrl-D (i.e. EOF) to exit

> >>>

Less pedantic, less passive agressive. Doesn't fake being nice to the user.

No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and forcing it into a function after so many years was a terrible retroactive design choice.

Meh, the print change was fairly trivial. You could backport the print function in Python 2 codebases, and updating existing print statements to use the function was easy to automate. String changing from bytes to Unicode was a lot more painful, in my experience.

Unfortunately, it also had the effect of breaking language tutorials going all the way up to "hello world". A tough experience for new learners, who are least able to debug those simple errors.

Back when Python 3 was first released, the error message was not so clear, either...

That was just the surface. Even the Python Foundation knew that their 2to3 converter tool just wasn't sufficient and hat to delay the discontinuation of Python 2 for half a decade, because there was so much unportable code out there. In the end we had 12 years where the two languages lived side by side and my first job using Python had us use 2.7 for new projects due to library concerns despite 3 being around for more than 7 years already.

Orthodoxy has never been my strong suit.

I have a pragmatic take on this if only because of Python's ease of throwing a script together and its non-technical userbase. Were it something that effects correctness I'd more fully support this break of backwards compat.

This is why I appreciate languages with a strict and non-strict mode. Let me make that choice. In particular, if the parser is intelligent enough to understand what I meant and is just throwing a syntax error to be pedantic, then let me control that. Needlessly taking choices away will always be a frustration.

The downsides of having both strict and non-strict mode:

- It is a maintenance burden on the compiler/interpreter writers to allow both modes

- There may be unexpected behavior when you use code from two different sources; one that expects strict mode and the other expects non-strict mode

- There may be interpersonal conflict when developers working together prefer one mode over another

Here’s a good overview of the details between the two: https://snarky.ca/why-print-became-a-function-in-python-3/

“Why don’t we just keep both?” probably has many answers. The overwhelming one for me is that if everyone’s doing the same thing two ways, then everyone has to learn all the esoterics about the print statement.

“Why don’t you just do it for me?” is a cardinal sin for a runtime. And already exists in migration tools.

Being able to use it in higher-order functions is somewhat un-Pythonic but I can accept that as a reasonable use for it. Would still prefer that print the statement is deprecated but usable.

I think composition is becoming increasingly more within pythonic idioms... it is well suited towards pythons usage as a high-level controller around low level libraries in other languages.

see also: the recent addition of match semantics in python

The problem is that the older syntax had way more ad-hoc oddities than just the lack of parentheses. Having to support weirdo statements like `print "hello", "world" >> sys.stderr` complicates the parser a lot and creates ambiguities, especially if you try to have it be both be this special-case statement and be a function object.

Is `print >> obj` a print call with redirection to the file-like `obj`? Or is it a operator call between those objects? What does `f = print` do, assign the function object or the result of calling print with no arguments?

I don't believe that the problem was that "having two forms of print is nonoptimal"; I believe the point was instead to remove a parsing ambiguity, which in turn allowed a whole class of errors to be caught at load time that previously weren't; and allowed the syntax to be extended in other new ways that previously couldn't have been encoded as parse rules due to the ambiguity.

While the Python3 lexer is specifically hacked up to recognize 'print' as a distinct lexeme — and to thereby emit an additional parser meta-instruction lexeme that triggers a special error-handling path in the parser if you then go on to make a syntax error per the newer uniform syntax — it doesn't actually know what you were trying to print. (That'd require a successful parse!) If the Python3 parser tried to do the compatible thing, that'd require ditching the uniform syntax altogether, and going back to the ambiguous parser.

It's a bit like Error Correcting Codes — the uniform Python3 parser knows enough to know that you did something wrong, and is provided by the lexer enough context to guess what kind of failure it was; but it doesn't have enough information to "Do What I Mean", because that's a strictly-greater amount of information.

If you type `func "arg"`, you get a generic syntax error.

If you type `print "arg"`, the syntax error is a bit more informative, but I wouldn't say that the compiler "understands" what you mean. It's just making a guess based on the fact that the previous token was "print".

On the other hand, supporting a special call syntax just for print, which includes more than just parentheses, would be substantially more complex. And then Python code in the wild would be more inconsistent and there will be endless debates about `print <args>` versus `print(<args>)`.