Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

501–510 of 513 posts

Re: Python 2 removed from Debian

#501

Earlier quoted context omitted.

But what if you just write a Python3 script and want to run it? Not a full blown application, but just a script. I mean the Python ecosystem is such that now I have to "package" up this script to potentially tell the user with Python 3.6 that they need to download a new interpreter version (eg 3.9) to run my application (and any dependencies). This puts all the pain of running a script on every user that wants to run…

If you just want to write a script, you likely know the version available on your system. When in doubt, add the #!/bin/env python3.10 shebang to the top of your script to ensure the version it's running on is the same as the version you're writing the script for. If I build an application on Linux I need to specify a glibc version or a PHP version or a Java version in some way as well. I don't see what this has to d…

> Good luck running a jar built with JDK19 on JRE8, or an executable linked against glibc2.36 on Ubuntu 18, or a Python file written for Python 3.10 on a system that comes with Python 3.6.

Yes, you are starting to see the problem. This is why I recommend statically compiled binaries as a solution to this scenario, and do not recommend any of the above.

Here's a real scenario I've had in my career, when deploying a script to 350k systems. I know I have Python 3.x, but I cannot count on the fact that every (or most) clients will have even a functioning Python interpreter. So what's the solution? Ship a docker container to everyone? There are multiple ways to solve it, but I complied a statically linked binary instead of writing a Python script...and had no issues.

> If you need dependencies, specify and install them.

Here be dragons, and this is the entire reason I avoid Python when I need my code to 100% work on another machine I can't fully control. I choose statically compiled languages in these instances. In a server deployment...sure it's fine because I can control that.

> Python 3 is completely backwards compatible in my experience

I do not agree. If you write a script that uses any of the following features and try to run on $version -1 (or more), your script will fail.

  * 3.6, F-strings were introduced  
  * 3.7, Dataclasses and introduced 
  * 3.8, Walrus operator (:=) 
  * 3.9, merge (|) and update (|=) operators added to the built-in dict class
  * 3.10, structural pattern matching
  * 3.11, exception Groups and except*¶ 
All use of these will fail to function in a previous release.

Maybe you'll say to just install a new version of Python. All that is overhead and requires more management. Ok, that's fair.

The problem is when you want to run that script on a bastion host, or a prod server, 350k machines, or a server you don't have ability to download and install external binaries? (all of these are real scenario's I've experienced).

My experience has taught me that if I can't control the machine the script runs on, I save headaches by using statically compiled languages. As always, YMMV.

Re: Python 2 removed from Debian

#502

As someone who does not use Python , the end result of this is that I now look into whether random utilities I use happen to be written in Python, and if so try to find an alternative. This is because I felt the pain of this transition -- again, as someone who does not program in Python. It has been miserable every time some random utility starts complaining that Python 3 is missing and then somehow when you install…

This is the top comment? In the year 2023?

OMG, that's a parody I hope!

Re: Python 2 removed from Debian

#503

Earlier quoted context omitted.

This rant feels like it would have been relevant in 2016-2018 or so, but in 2022-2023 I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. Once Python 2 officially EOL’ed the ecosystem basically managed to port whatever was important enough to keep using over to Python 3. Im sure some legacy megacorps are still doing stuff in Python 2 but that’s no different from these corps running so…

"rant"? Is that what a criticism of a technology that you like is called? I feel your response is best summarized as: "I like Python. I've never had this problem and don't think it's a legitimate problem. Only $megacorp users have this issue, and their concerns aren't important." If you dismiss the problem (as you've done) then you don't have to intellectually address it. The Python 2 -> 3 transition was hard for tho…

Dude, Python 2 is dead since 3 years officially, and was burred already almost a decade ago.

Whoever missed that is self responsible for all self harm done by ignoring that.

Re: Python 2 removed from Debian

#504

Earlier quoted context omitted.

Okay, but surely my poorly written dockerfile that grabs the wrong images and runs broken code is not Debian's or python's problem? Older versions of debian that still support python2 will theoritically be around forever, and any codebase that absolutely needs them should always work. (though I contend that, given that we've had 15 YEARS of warning that this was coming, such instances should be vanishingly rare and n…

> … "given that we've had 15 YEARS of warning that this was coming" … This right here is the part that I'm still having troubles wrapping my brain around. People still stressing about Python 2 "going away" (it's gone folks; accept it) despite the fact that there's been well beyond a decade of advance warning, and Python 2 having been officially EOL ages ago now.

People won't move until heavens fall down on them.

And than they will start complaining that it's other peoples fault that they didn't move.

Re: Python 2 removed from Debian

#505

Earlier quoted context omitted.

Uh, Python 2 was aboslutely fine at working with non-ASCII text as long as the only operations you try to do on it are "take the length" and "reproduce a string verbatim". Notably, it did not forcibly explode when encountering a character appearing in a comment or string literal or whatever that couldn't be interpreted as utf-8. This was a real step back for code that, oh, say, used filesystem interfaces to look at u…

Not if “reproduce the [possibly Unicode] string verbatim” includes concatenating it with others in order to insert it into some sort of context, that will absolutely blow up if you’re not careful and unfortunate input data comes in (I hope that happens before the code enters production!). For comments and string literals in Python code, note that Python 3 changed the default from Latin-1 to UTF-8, but you can still u…

This is true, almost all "string" operations require you to know extra information about the string's "type"—which, yes, includes its encoding.

Python 3 takes this fact and runs with the stance that strings should, by default, carry their encoding with them (and that encoding is specifically, more or less, a sequence of quasi-Unicode code points with unspecified internal representation). But this is an intensely half-baked solution to the wrong problem, because you need to know much more about a string than its encoding for just about any string operation you'd want to do. Just with Unicode code point concatenation, you can run into plenty of trouble with: - strings containing control characters - strings with unpaired surrogates (which okay, shouldn't really be there, but get used for various reasons anyway) - strings containing combining characters - strings in different natural languages - strings in languages with ligatures - strings with ligature-like emoji (and this is obviously not remotely close to exhaustive.)

Re: Python 2 removed from Debian

#506
post #499

Earlier quoted context omitted.

> I feel like a lot of the people who had this reaction were reacting to being told (correctly) that how they handled strings was broken Can you be very precise about what you mean by "broken" or "incorrect" code?

In python2 you can easily mix encoded and unencoded strings. This doesn't actually work, but at worst it'll produce mangled strings. You used to see this sort of thing online quite a lot with webpages having all sorts of weird characters and question marks showing up. Python3 enforces the difference between encoded and unencoded strings. It forces you to deal correctly with unicode. If your code base was already hand…

There are many codebases in the world that never need to deal with Unicode. Therefore, new language features which deal with Unicode are unwelcome when they replace the existing string API (which was often used to handle raw bytes)

Re: Python 2 removed from Debian

#507

As someone who does not use Python , the end result of this is that I now look into whether random utilities I use happen to be written in Python, and if so try to find an alternative. This is because I felt the pain of this transition -- again, as someone who does not program in Python. It has been miserable every time some random utility starts complaining that Python 3 is missing and then somehow when you install…

I tried to learn Python around 2008-2009 and it was literally the worst time to try to learn Python, the transition to Python3 was just beginning, take 2 random code samples from the internet and they won't work together, python2to3 didn't work either.

It's kind of a shame how this transition took more than 10 years. The good part, we learned that we don't have to go through the same again. of course I dropped python (I was like 18 years old and didn't know anything about programming), I had to learn python last year and you still can see a lot of stuff that makes the experience kind of annoying.

Anyway, I'm pretty impressed how Python still is in the first positions of most charts, I still fail to see how great the language is, but hopefully I will be able to someday soon :)

Re: Python 2 removed from Debian

#508

Earlier quoted context omitted.

That's cool, but if the 100 year old saw had been used regularly it would have required maintenance and sharpening to continue working well. Software also requires maintenance. I can't think of any 100-year old software that is being used today (ha-ha). I'm sure some airline reservation systems and banking systems written in COBOL in the 70s are still around, but they all have ongoing maintenance to keep them working…

>This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple. Why should I, an end user, ever need to build WikidPad? I don't need to do so on Windows, why doesn't Linux support the same thing, shipping an executable? When you go to the store, you're not presented with a set of tools for making a saw, you're given a complete, ready to go tool. Perhaps the very idea o…

First comment is a complain about python and the first thread is about saws and woodworking tools.

Truly a hacker news experience.

Re: Python 2 removed from Debian

#509

Earlier quoted context omitted.

Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that. How about one with dataclasses support? Again, you get to install a new interpreter everywhere. Python packaging continues to be a sore spot for the language.

You're getting the Python version you've specified as a requirement in your requirements.txt, unless your users ignore or bypass that. What language features you support depend on the minimum version you pick, and if you choose to go bleeding edge/not pick a version/pick a version and use newer features anyway, you're responsible for getting support to work.

requirements.txt doesn't support putting your python version in it

Re: Python 2 removed from Debian

#510

Earlier quoted context omitted.

You're getting the Python version you've specified as a requirement in your requirements.txt, unless your users ignore or bypass that. What language features you support depend on the minimum version you pick, and if you choose to go bleeding edge/not pick a version/pick a version and use newer features anyway, you're responsible for getting support to work.

requirements.txt doesn't support putting your python version in it

You're right, I misunderstood environment markers.

However, you can ensure compatibility around this by specifying the required version in the top of your script:

    import sys
    minimum_version = (3,6,1)
    if sys.version_info 
This will work because of how Python's tuple comparison works.

As long as you put this above any code requiring any specific version (this will work with Pyton 2.7, I don't have anything older to test) this will halt execution on dependency failures.

You can include these checks in your setup.py if you want to rely on Pip so users are warned on install time. You could probably also add this to some wheel trigger if you add a local/public package as a dependency in your requirements.txt.

Post reply on HN