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

Python 2 removed from Debian

bugs.debian.org

Post reply on HN
Print view View original

491–500 of 513 posts

Re: Python 2 removed from Debian

#491

Post by mananaysiempre »

naniwaduni wrote: post #406
mananaysiempre wrote: post #199

Earlier quoted context omitted.

> No, it's not even remotely worth the amount of confusion and work it caused. Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of m…

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 use -*- coding: -*- to change that. Bytes literals outside of ASCII range you’ll still have to escape. As for program input that’s possibly invalid UTF-8 but not in places you care about, you’ll need to set errors='surrogateescape' or similar explicitly (or possibly set an 8-bit encoding like Latin-1, though not if there’s a chance of UTF-8 in places you do care about).

Paths are a bit painful, yes, both because there’s nothing on Unix systems that precludes /home/alice having filenames in UTF-8 and /home/boris in KOI8-R, and because NT paths are not byte sequences at all (they are WCHAR, that is 16-byte-number, sequences, in no way required to be representable in the current CP_ANSI). Having uninterpreted byte sequences as filenames would work to solve the former issue, and it does: I think most functions in os will accept bytes paths as input and treat that as a signal that you want bytes paths as output (if any). For the latter the cleanest solution is probably an abstract Path type—and you get one, in the standard library’s pathlib. That didn’t work all that well in early Python 3 versions, but it does now. (And IIUC inspired Rust’s abstract-type solution to the problem.)

Re: Python 2 removed from Debian

#492

Post by mikewarot »

jasonmp85 wrote: post #482
mikewarot wrote: post #480

Earlier quoted context omitted.

It seems the actual problem is a disagreement on how tools SHOULD work. A saw still works after a decade on a shelf, programs should still work too because they are tools.

What shelf? A garage? Detached? A shed? How humid? You may want to resurface and oil that saw after a decade. The wood handle may have rotted, or the plastic one may be gummy. Taking care of tools is how they last.

The 100 year old saw I inherited and used to cut down a broken tree last year.

Re: Python 2 removed from Debian

#493

Post by _eht »

dang wrote: post #490
_eht wrote: post #408

Earlier quoted context omitted.

[flagged]

We've banned this account for repeatedly and egregiously breaking the site guidelines. Not cool. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html .

[dead]

Re: Python 2 removed from Debian

#494

Post by Apofis »

tolmasky wrote: post #286

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 just avoid Python and any job descriptions that contain it. It's never been a good experience for me, whether as an end user or a developer. It's nice that they may have ironed out their issues, but I've been done a long time ago. There's nothing Python does I can't do better with some other toolchain.

Re: Python 2 removed from Debian

#495

Post by vonseel »

mikewarot wrote: post #492
jasonmp85 wrote: post #482

Earlier quoted context omitted.

What shelf? A garage? Detached? A shed? How humid? You may want to resurface and oil that saw after a decade. The wood handle may have rotted, or the plastic one may be gummy. Taking care of tools is how they last.

The 100 year old saw I inherited and used to cut down a broken tree last year.

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

The commenter's complaint seems particularly worse with dynamic languages like JavaScript and Python than compiled things. Old projects written in node are often just as hard to get running or installed as something written in Python 2. The dependencies are out of date, you have to install an older version of Node.js, or the dependencies just don't exist anymore. And JS stuff usually generates a huge tree of dependencies even if they only directly rely on a handful of packages.

End of story, I think if these Python-2 tools/scripts were such a huge part of his project that they keep breaking builds, the company should be invest time in either rewriting them in their language of choice or maintaining those projects or a fork of those projects.

One of my old bosses was strict about this - no COMPANY projects should be relying on external package repositories, unapproved third-party dependencies, definitely not some github project maintained by only a few people. Yeah, I think if your company is relying on "requests" or some other massively popular project with tons of community maintenance, you don't want to fork that and it's important to use the standard versions. But if you're bringing in something that is used and maintained by only a few people - you either need to become part of the community that maintains it publicly or fork the project and maintain your own version.

This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.

Re: Python 2 removed from Debian

#496

Post by mikewarot »

vonseel wrote: post #495
mikewarot wrote: post #492

Earlier quoted context omitted.

The 100 year old saw I inherited and used to cut down a broken tree last year.

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 of users having to build things in Linux is the problem?

It is very similar to the problems with Windows, always pushing updates/upgrades that aren't necessary, and often break things. Windows machines are far less reliable on Wednesday than they are on Monday, because of Microsoft's idea of pushing patches on Tuesdays.

Re: Python 2 removed from Debian

#497

Post by jeroenhd »

bloblaw wrote: post #387
jeroenhd wrote: post #361

Earlier quoted context omitted.

I think it's actually more excusable in recent scripts as Python 2.7 has been deprecated and unsupported for ages now. You won't know what version of Python 3 you're getting, but at this point it's safe to assume you're getting a version of Python 3 when you call python. Only old scripts written when Python 2 and 3 were maintained separately should've ever had this problem, but we're past that point now.

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.

Re: Python 2 removed from Debian

#498

Post by bloblaw »

jeroenhd wrote: post #497
bloblaw wrote: post #387

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.

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

I've said it before, but Python requires users to replicate the developers environment...and somehow this is fine?!? Statically compiled languages (eg Go, Nim, Rust, C/C++, Obj-Pascal, D, etc) ship binaries...that just run.

Obligatory xkcd: https://xkcd.com/1987/

Re: Python 2 removed from Debian

#499

Post by Doxin »

someguydave wrote: post #384
dkarl wrote: post #317

Earlier quoted context omitted.

> and were smug about it 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. A big reason that projects had difficulty upgrading, especially difficulty using the automatic 2->3 upgrade tooling, was because of broken handling of unicode and broken handling of binary strings. I remember reading a quick assessment of a large open-source…

> 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 handling unicode correctly it wasn't much hassle to migrate. If your code base was making a mess of unicode handling --like many at the time were-- you'd run into that headfirst.

Re: Python 2 removed from Debian

#500

Post by jeroenhd »

bloblaw wrote: post #498
jeroenhd wrote: post #497

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.

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 do with Python. 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.

Statically compiled languages come with their own problems (note that C++, Go and Rust also have system requirements, I've had to deal with a Go executable that would not work in a musl environment and a Rust executable that I needed to build on Ubuntu because the compiled version from my Manjaro laptop linked a against a libc version that was too recent).

If you need dependencies, specify and install them. If your only dependency is the interpreter, document it, specify it in the shebang, or deal with it. Python 3 is completely backwards compatible in my experience, it's only the programs that stuck with Python 2 for a decade that have trouble running on modern machines in my experience.

Post reply on HN