Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

361–370 of 513 posts

Re: Python 2 removed from Debian

#361

Earlier quoted context omitted.

The number of times I find a script that blindly assumes 'python' points to its required version is too damn high. It makes me question the general competency of the people shipping Python code.

It’s inexcusable in recent scripts, but some of these date from the time when there was only python2. No, the root of the problem, as pointed out by many others here, is the policy decision to create two incompatible interpreters both called “python”.

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.

Re: Python 2 removed from Debian

#362
post #332

Earlier quoted context omitted.

I think part of the issue is that your comments are very ambiguous as to what issues you actually hit. Most of the major Python packages did maintain 2 and 3 compatibility at the same time. Maybe a few packages had bad coding practices but you’re going to hit that in any language. I think you’re extrapolating unfairly

> I think you’re extrapolating unfairly But that's exactly the nature of doing this sort of change. Again, I am not a Python person. This transition created an unintentional filter where the utilities with poor practices surfaced to end users , such that their only direct interactions with Python are always negative. So sure, the extrapolation may very well be unfair, but that is the completely avoidable situation th…

Tons of other languages have version requirements as part of their end user experience.

Whether that’s libc requirements for compiled languages, or Perl language versions being breaking, or even as subtle as differences in behaviour between different compilers such that your system may give different results than another user.

So I disagree with your assertion here.

Yes it’s unfortunate that this is lifted up to the user, especially because of the fact it’s interpreted, but it’s not anywhere near unique to Python.

Therefore I think it’s not a logical outcome to outright avoid Python.

Re: Python 2 removed from Debian

#363
post #359

Earlier quoted context omitted.

It's as if JavaScript had shipped a non-compatible update, browsers had on a magic day stopped supporting the old JavaScript, and all of a sudden her crossword website stopped working because that site's developer didn't update the JavaScript. This grandma sure complains a lot about broken websites for someone who supposedly doesn't know what JavaScript is. What an entitled grandma. Why doesn't she just build Linux f…

[flagged]

That is precisely what happened: I don't write Python (grandma doesn't write JS). Python changed (JS changed). Environment stopped supporting the old one (browser for grandma, package manager for me). End-user apps didn't keep up (website for grandma, the apps for me). I am now forced to go resolve these issues. This is 100% analogous. Please explain how it is not. In both scenarios you would blame the "app developer" (in the Python case you would blame app/library developers for bad dev practices or whatever, in the hypothetical you would blame the website developer for not updating the crossword page), and the end-use for being entitled (in my case, the user of various apps that are broken, and the grandma using the crossword website). You supposed solution is that we should either not complain, or I guess, ironically, just learn the base systems better to be more on top of things so we can compensate for the bad dev practices ourselves.

Also, I am not "trying hard" not to care about Python. I specifically said in my very first comment I go out of my way to avoid it now. I think that falls in the "cares" category. My default state is to not be aware of what language things are written in. I don't know if some given tool is written in C, bash, or JS. If I were to coincidentally learn what language it was written in, it might serve as a curiosity, but not really phase me either way. However, I was forced to become aware of a bunch of Python stuff since it started breaking, and then forced to learn about all the weird workarounds to get it working. Given that I was forced to repeatedly deal with dependency hell with apps in this language, I am now choosing to avoid it if I can in the future if I learn that an app is written in it.

Re: Python 2 removed from Debian

#364
post #359

Earlier quoted context omitted.

[flagged]

That is precisely what happened: I don't write Python (grandma doesn't write JS). Python changed (JS changed). Environment stopped supporting the old one (browser for grandma, package manager for me). End-user apps didn't keep up (website for grandma, the apps for me). I am now forced to go resolve these issues. This is 100% analogous. Please explain how it is not. In both scenarios you would blame the "app developer…

[flagged]

Re: Python 2 removed from Debian

#365

Earlier quoted context omitted.

Strings are still strings in Python 3; if you do 'foo' == EnumValue then that will work fine in Python 2 and 3. If 'foo' is from an unknown source: yeah, you might get a bytes type in Python 3 and an error, but that's the entire point. Turns out that in practice, it can contain >0xff more often than you'd think. Certainly today DNS domain names, URLs, and email addresses can – and do – contain >0xff input, and for so…

> DNS domain names, URLs, and email addresses can – and do – contain >0xff input Is that true? My understanding is that DNS never supported non-ASCII and so punycode was invented.

But is also very rare that you ask directly for domain name resolution in the first place; you are usually instead using something directly or indirectly that happens to be remote, and that eventually happens to have a punycode encoded non-ascii hostname or top level domain. But there's no garantee that you (or the libraries, or the libraries that your libraries use...) are only handling the ascii punycode.

I can count on my fingers the number of places I invoked manual DNS lookups inside production code.

Re: Python 2 removed from Debian

#366

Earlier quoted context omitted.

I mean... https://www.w3.org/International/articles/idn-and-iri/ https://www.rfc-editor.org/rfc/rfc6531 etc... Just because you can get away with ignoring the non english speaking world doesn't mean Python should pretend it can.

You can't use Unicode characters in HTTP messages - IDNs and IRIs are encoded into ASCII before being sent on the wire (using punycode for IDNs and percent encoding for IRIs). As for RFC6531, my understanding is that virtually no email provider implements it, because of the same risks that make browsers often show IDNs as their punycode version - Unicode is extremely easy to use to confuse people maliciously or accid…

In Germany, there are two competing flight comparison engines with very similar names: fluege.de and flüge.de.

How would you send an email to the customer support of flüge.de? How would you parse that domain?

IDN is here, and it's here to stay.

Re: Python 2 removed from Debian

#367
post #364

Earlier quoted context omitted.

That is precisely what happened: I don't write Python (grandma doesn't write JS). Python changed (JS changed). Environment stopped supporting the old one (browser for grandma, package manager for me). End-user apps didn't keep up (website for grandma, the apps for me). I am now forced to go resolve these issues. This is 100% analogous. Please explain how it is not. In both scenarios you would blame the "app developer…

[flagged]

This is a weird gate-keeping response.

Re: Python 2 removed from Debian

#368
post #354

Earlier quoted context omitted.

> I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does no…

This is such an odd and entitled take for a person who is really trying hard not to care about python.

I prefer Hg over Git but I use Git. Why? One time I tried to use hg command and it didn't work. Why? I was on a system that had incompatible Python interpreter to the Hg scripts.

That was it. Since then I use Git everywhere even though I prefer Hg.

Re: Python 2 removed from Debian

#369
post #364

Earlier quoted context omitted.

That is precisely what happened: I don't write Python (grandma doesn't write JS). Python changed (JS changed). Environment stopped supporting the old one (browser for grandma, package manager for me). End-user apps didn't keep up (website for grandma, the apps for me). I am now forced to go resolve these issues. This is 100% analogous. Please explain how it is not. In both scenarios you would blame the "app developer…

[flagged]

It's always amusing when the other person has to fall back on "The tricks on you! You invested time talking to me, while I deviously spent way less time and put less thought into my arguments. Don't you feel foolish now?" No, not really. As it turns out writing a couple paragraphs does not meaningfully impact the progress of my other work. And I would assume that's the case with most people.

Maybe one day you can get past DH0: http://www.paulgraham.com/disagree.html

Re: Python 2 removed from Debian

#370
post #83

Earlier quoted context omitted.

The removal of implicit conversion between bytes and strings via ascii did not introduce bugs, it showed were you already had bugs that you maybe did not yet notice.

That's only true if you ever received Unicode input. There are plenty of uses of strings that never do - enums, DNS domain names, URLs, HTTP parsing, email addresses (from any sane provider) etc.

Indeed, I just had to port some code that had been running happily for years at the south pole to py3 (due to EL8 upgrade and not wanting to install the py2 world). It was something talking to a HV supply over a serial port which of course only spits out bytes, but then needed to parse using string handling. It wasn't that hard to port but it took a few tries to find all the places necessary, requiring debugging over a rather slow ssh connection (that is only up when the satellite is up).
Post reply on HN