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

221–230 of 513 posts

Re: Python 2 removed from Debian

#221

Post by wink »

yen223 wrote: post #122
whirlwin wrote: post #44

As mentioned by several people already, the migration process from 2 to 3 was really painful. It will be easier for the Python core maintainers, but introducing a breaking change with the intent that that version 2 will be deprecated has probably caused more distress overall, especially maintainers of other open source projects which rely on a specific python version. Let's never have the same kind of breaking change…

I see people saying that the migration was painful, but my own experience with two separate Python 2->3 migrations were so smooth they might as well have been a minor version bumps. I don't know where this discrepancy comes from.

See my other comment, we started a Python 2 project in late 2013 (Python 3.0 was released in 2008) because of all the dependencies we wanted to use were not ported (yet, no clue if they ever were).

Re: Python 2 removed from Debian

#222

Post by bayindirh »

ilyt wrote: post #195
bayindirh wrote: post #82

Earlier quoted context omitted.

This is also how Debian did it, too. Actually it's probably propagated from Debian Unstable to Ubuntu. You need to install either "python-is-python2" or "python-is-python3" packages to get proper system-wide symlinks. Also, it was strictly verboten to give either of two packages as dependencies to workaround migration procedures. Debian Testing doesn't have Python2 at least for a year now.

I've upgraded debian thru the ages and /usr/bin/python defaulted to python2. Didn't need to install anything for that to happen, maybe if you installed debian from scratch Another mistake in Py3 migration was keeping the interpreter name as python so when you had it in path you had a choice of new stuff breaking or old stuff breaking

> I've upgraded debian thru the ages and /usr/bin/python defaulted to python2

It was, in the past.

When python2.7 deprecated and removed in Debian testing, python ceased to exist as a command. You need to install these packages (python-is-python{2,3}) to get the python command and point to the correct interpreter you like.

This behavior is consistent in two Debian testing systems, installed 6 and 9 years ago, respectively.

> Another mistake in Py3 migration was keeping the interpreter name as python...

I installed python-as-python3 myself, after python2 disappeared from system to fix an oddball python3 script which bundled as a part of a bigger software package which is not in official repositories.

Maybe they have fixed it, but I didn't bother to check till now. I'm not even sure which program it was.

So, it was an addition to a clean system and didn't inadvertently directed python2 code to python3 interpreter.

Re: Python 2 removed from Debian

#223

Post by Beltalowda »

tsimionescu wrote: post #200
Certhas wrote: post #192

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…

No doubt some things broke "needlessly", or that things couldn't have been done better, but I don't see how it could have been avoided since there is no way to distinguish between "I know that this string will always be ASCII" vs. "this string can contain non-ASCII".

For example, what if I want to enter "ουτοπία.δπθ.gr" in an application, via direct user input, a config file, or something else? Or display that to the user from punycode? No one expects users to convert that manually to "xn--kxae4bafwg.xn--pxaix.gr", and no one will understand that when being displayed, so any generic IDN/domain name library will have to deal with non-ASCII character sets.

The same holds true for email addresses: "ουτοπία " is an email address. Sure, this may get encoded as "=?UTF-8?q?…?=" in the email header (not always, "bare" UTF-8 is becoming more common) but you still want to display that, accept it as user input, etc. People sometimes to forget that the name part of an email address is widely used and that any serious email system will have to deal with it, and non-ASCII input has been common there for a long time.

In specific applications you can often "get away" by ignoring non-ASCII input because you sometimes don't need it. For example I'm working on some domain name code right now which can because everything is guaranteed to be ASCII or "punycode ASCII", so it's all good. But in generic libraries – such as those in Python's stdlib – that's much harder.

Re: Python 2 removed from Debian

#224

Post by nmstoker »

Having primarily used Python 3 since 2016 with some very specific (rare) exceptions and having found the switch remarkably pain free it's difficult to empathize with those still going on about this like it was massive, and yet there are major banks still struggling with the transition in key areas so there must be something.

Is there a risk it becomes like one of those situations where certain people use a topic simply to make conversation? Or the modern exaggeration to avoid seeming boring? Or a bunch of "oh, it's gonna cost ya" contractors plying the age old lines of car mechanics negotiating basically anything. Someone below referred to carnage. I wonder how far off we are to someone claiming it was actual violence.

Re: Python 2 removed from Debian

#225

Post by Beltalowda »

secondcoming wrote: post #213
Beltalowda wrote: post #205

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.

DNS-the-protocol still doesn't support non-ASCII input, but DNS-as-people-use-it does. I expanded on that in another comment I just posted, so I won't repeat it here: https://news.ycombinator.com/item?id=34230218

Re: Python 2 removed from Debian

#226

Post by mananaysiempre »

wink wrote: post #217
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…

Not the one you replied to, but we were doing things mostly without strings (audio processing, stuff with bits) and python 2 worked perfectly fine. We had started this project as late as 2013 because the important libraries had not been ported yet and when the stuff wrapped up in 2017... I'm not sure if we could have switched by then. So personally I'm ok with Python 3 but I actually never ran into the described prob…

So not a single Cyrillic path in your INI or CSV files, or in the user input (CP_ANSI) to be printed onto the Windows console (CP_OEM, unless you’re in IDLE or redirecting the output, in which case CP_ANSI)? (The standard library’s CSV module was particularly atrocious at Unicode as I remember.) Not a single Chinese comment in your hardware descriptions? I envy you, but that’s a still a very specific corner of the world.

Re: Python 2 removed from Debian

#227

Post by Attrecomet »

t43562 wrote: post #129
ahartmetz wrote: post #60

Earlier quoted context omitted.

Very strange, about the whitespace. I write C++ most of the time and I love significant whitespace. I like the combination of power and (...these days, relative...) simplicity of the language for all kinds of helper tools. Probably wouldn't want to use it to write something that is large and / or needs to run fast.

The best thing about significant whitespace is the reduction in pernickety code review comments about it compared to other languages. If you also agree to "just run black" to format code then that kind of bullshit drops to almost 0 in a team.

The bad thing about significant whitespace is it breaks copy-pasteability of code, with no way to get broken formatting back without understanding what the code does.

That is a lot worse than formatting squabbles, especially for a glue language where you are expected to be able to copy snippets for short scripts all the time.

Re: Python 2 removed from Debian

#228

Post by harriet1 »

wink wrote: post #217
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…

Not the one you replied to, but we were doing things mostly without strings (audio processing, stuff with bits) and python 2 worked perfectly fine. We had started this project as late as 2013 because the important libraries had not been ported yet and when the stuff wrapped up in 2017... I'm not sure if we could have switched by then. So personally I'm ok with Python 3 but I actually never ran into the described prob…

[dead]

Re: Python 2 removed from Debian

#229

Post by Beltalowda »

solarkraft wrote: post #202
sherr wrote: post #133

It was a bit of a shock when I upgraded my Debian systems to Bullseye (11) from Buster (10) a year or so ago. I discovered that the wiki I've been using for years, Moin Moin, was removed because it didn't support Python 3. I've a lot in the wiki and was in no position to migrate, so I made a wiki only VM and keep it at "oldstable". Since none of it is internet-facing, I can keep it this was forever, even once all sup…

What shocks me is that MoinMoin doesn't support Python 3.

It looks like the MoinMoin people decided to rewrite a lot of stuff for Moin 2 (which does support Python 3), but that hasn't been finished yet and has been in the works since about 2010.

That's my impression from https://moinmo.in/MoinMoin2.0 anyway.

Re: Python 2 removed from Debian

#230

Post by Attrecomet »

t43562 wrote: post #139
erik_seaberg wrote: post #21

Earlier quoted context omitted.

Survivorship bias. Teams whose projects were seriously derailed are more likely to have stopped using and relying on Python.

Too bad for them. The rest of us get improvements. I'm way tired of being forced to use old C++ compilers because "upgrading is non revenue generating work". If you think rewriting your code in some other language is easier than upgrading to Python 3 then good luck to you.

And modern C++ is still being held back for deathly fear of breaking ABI despite clear improvements it makes impossible. People here seem to underestimate the cost of keeping backwards compatibility forever -- either you change very, very slowly (C) or your change is a clusterfuck of disparate requirements that keep blocking each other (C++).

Of course, "We want this code to run forever the way it is" is a value option that a company can choose - just not with any language it wants. And somehow, people seem a bit reluctant to switch from Python to C to be able to keep running the same programs forever, guaranteed.

Post reply on HN