Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

341–350 of 513 posts

Re: Python 2 removed from Debian

#341

Earlier quoted context omitted.

> This is totally false - code produced by 2to3 no longer ran on 2. That's what "breaking changes" and "backwards incompatible" means. What exactly is hard to grasp? > So you ended up w a chicken and egg problem. You really don't. Your code and your upstream dependencies need to be ported to python3. Once your dependencies are updated, all that's missing is you doing your job. Python2 has been on the path to deprecat…

“It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes.” What is it about python 3 that brings out this lecture stuff. I would really like to see the inside of this “easy” change at even the bigger most well resourced places. Google / Facebook / Dropbox etc. At small places where a program is working and programmer is gone they are not investing in…

> Yes, they did put u”” back in. No it did not destroy the world.

This saga isn't completely over, over here: We still have code running python2 that we don't have the room to upgrade, and libraries that have to work with both python2 and python3. Meanwhile, people are pushing "code consistency" to the point where people outside our team are taking those libraries and running the "black" formatter on them - but "black" doesn't understand python2, so it removes the "u" prefix and breaks the library.

Re: Python 2 removed from Debian

#342

Earlier quoted context omitted.

This is totally false - code produced by 2to3 no longer ran on 2. So you ended up w a chicken and egg problem. Things like u would allow folks to keep compatibility with 2 while working in 3. Your comment is a perfect illustration of the issues. Lots of user blaming. No actual solution. As I said, it did start to get massively better at some point. Instead of condescending lectures on org issues they for example bega…

> This is totally false - code produced by 2to3 no longer ran on 2. I don't see where GP made a claim that it would. Why would one expect code written for a newer version, using features that don't exist in an older version, to run under the older version?

If you published libraries on pypi you were in exactly that nightmare scenario. How do you support users on both versions of python (because let's be real, it took _ten years_ to change so you had to support both major versions) without two totally separate codebases and all the massive headaches that entails. There were some partial solutions like the library six and all kinds of related tricks to write python that was compatible with both 2 and 3 at the same time.

Re: Python 2 removed from Debian

#343

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 not just a Python problem. I remember when PHP shifted from 5.6 to 7 - I used many projects and software which needed to be updated because e.g. all the mysql_ functions and some crypto functions were removed.

Same Issue with e.g. converting Vue 2 to Vue 3 or Angular.js (Version 1) and Angular (Version 2).

I really hate when some programming languages or frameworks completely remove important functions which were used by nearly every project.

Re: Python 2 removed from Debian

#344
post #79

I like Python 3. It eliminated a whole category of encoding/decoding errors. Even Python 2 codebases benefited from it, as libraries were updated to handle Unicode better in an effort to achieve compatibility with Python 3. I didn't experience much pain migrating codebases to it, but I'm just speaking for myself here. Congratulations to Debian on upgrading to Python 3!

Yeah, coming from C#, Python 2's unicode support was so bad I almost abandoned it immediately as a Chinese speaker (and to make it worse, I use Windows). You literally can't use IDLE for learning/testing properly half of time due to encoding issues. And what surprised me most is that every time I mentioned this, there would be lots people telling me how this is a superior design because you can operate string like by…

FWIW, in Linux, this problem does not exist. Everything is UTF-8 and Python 2 would work just fine (and always did).

In order to support Windows better, Python 3 introduced support for UCS-4 (or worse, UTF-16) strings (depending on a compilation setting when Python was compiled) and they had to introduce extra string types to distinguish readable strings from binary strings ("bytes").

These extra types made Python 3 a lot harder to teach (I teach 30 person classes every year).

So it's not all roses now.

In the end, I got used to it, BUT I just gave up asking encode()/decode() questions at the exams. Very few people understand it, or care enough (and I understand why--it's a ridiculous thing to have). You only need it if your OS somehow slept through the introduction of UTF-8, which is backward compatible with ASCII, resilient even if there are transfer errors and can encode all unicode characters.

Encoding problem used to be really common in UNIX (and before that, in mainframes), but with the introduction of UTF-8, all encoding problems I had vanished and never appeared again.

Even Windows 10 has an UTF-8 mode now and the Windows API functions that end in "A" can be made to use UTF-8.

Now, in a sense, Python 3 has this entire complication for no reason.

That said, Python 3 is ok to use now--and, conceptually, distinguishing byte strings from unicode strings is better (for example so that you don't accidentially print the former to the terminal). It just uses up brain cycles that you could be using for solving your actual problems.

Re: Python 2 removed from Debian

#345
post #184

Earlier quoted context omitted.

The changes Python made was made in Perl without breaking compatibility, you just wrote say use v5.24 in header to use given feature set (defaulted to something old to not break old stuff) The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl. At the very least they should've just made new one…

Yes; and now we have to keep every version of Perl around in our package managers because they're all used by some code. That's terrible practice.

You don't. The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code.

If you don't write special in your code, Perl doesn't have a "say" method (because it didn't have one in Perl 5.8). If you declare in the code that you're code for Perl 5.10, magically there are all the Perl 5.10 features, including "say". You can also declare you want specific features, rather than declare a specific Perl version.

  $ perl -v | head -2 | tail -1
  This is perl 5, version 30, subversion 3 (v5.30.3) built for x86_64-cygwin-threads-multi
  $ perl -e 'say 1'
  Number found where operator expected at -e line 1, near "say 1"
          (Do you need to predeclare say?)
  syntax error at -e line 1, near "say 1"
  Execution of -e aborted due to compilation errors.
  $ perl -e 'use 5.010; say 1'
  1
  $ perl -e 'use feature "say"; say 1'
  1
The best thing about this is you can mix and match libraries from earlier and newer Perl versions. If a library says they want Perl 5.10, they get Perl 5.10, even if you want both Perl 5.30 and that library.

If only Python were as reliable for backwards compatibility.

The Perl community is going through their own Py2->3 moment, and they're doing it with great care. They're going to create Perl 7, which will be Perl 5 where the "defaults" make the language look more like Perl 5.32 rather than Perl 5.8 [1]. Modern Perl scripts don't need so much boilerplate to enable modern features. They know exactly the trouble this will cause; if Perl 7 ever becomes the default Perl interpreter, the only one, it _will not run_ lots of very old Perl scripts untouched, because the defaults will make years worth of language changes suddenly visible to those scripts. Even if the fix is just to slap "use 5.008" on every script, they worry about it. That's a much better attitude than the Python developers.

[1] https://www.perl.com/article/announcing-perl-7/

Re: Python 2 removed from Debian

#346

Earlier quoted context omitted.

Migrating where there’s a 1-1 mapping of old API to new API is easy, such as the print to print() change. The hard part is when there’s a 1-N mapping, where a single name in the old API becomes multiple names in the new API. These are the most useful changes to make, because they can split apart unrelated concepts that had been erroneously represented by the same object, but require a human to determine which use cas…

Python2 had the 'unicode' class for characters, and the 'str' class for bytes. The whole 2 to 3 debacle was only because somebody thought that naming your string class 'unicode' doesn't sound nice enough or something.

Also the default, what a no-prefix string like "foo" meant changed between the two versions.

Re: Python 2 removed from Debian

#348
post #186

Earlier quoted context omitted.

> It will be easier for the Python core maintainers, [...] It wasn't not even that easy, to be frank. 2to3 is not a small project [1] and they had (alas, incorrectly) assumed that there were enough people to have enough tests to be benefited from 2to3, only to be found massively wrong. In hindsight no one had a good idea about language evolution; the modern concensus is a single interpreter supporting multiple parall…

> In hindsight no one had a good idea about language evolution; the modern concensus is a single interpreter supporting multiple parallel versions, also called "editions", but (EDIT: to my knowledge) the first major language with this approach was ECMAScript 2009 (5th ed.) with `use strict` and Python 3 predated it. Perl did it since ages. You just put use v5.24 in header and interpreter enabled those language featur…

At Yahoo, we had a wrapper so we could have 5.6 and 5.8 installed (and later 5.8 and 5.10), and if you had use 5.6, you'd get 5.6, and use 5.8, you'd get 5.8, and neither, you'd get the default set for that machine.

If you tried to run a 5.8 script on a machine without 5.8, you'd get an error as should be expected. If you ran a use 5.6 script on a 5.8/5.10 machine, I think you'd get 5.8, but I can't remember... 5.10 was less disruptive than 5.8.

Re: Python 2 removed from Debian

#349

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…

>You have containers that have worked for years that all of a sudden error out saying "Python 2 is no longer supported,"

Isn't this precisely the problem containers are trying to solve? You can update your system, get rid of unsupported software, and still keep the older version of Debian within your container that depends on an unsupported version of Python.

Re: Python 2 removed from Debian

#350
post #332

Earlier quoted context omitted.

That was one issue I mentioned. You know that. You read my comments. However, I will take your snarky reply and turn it into lemonade by using it as an opportunity to talk about how often development teams fail to consider the social implications of their changes. As is mentioned in another comment on this post, the Python team seems to readily admit in retrospect that they didn't predict the pain of having no clear…

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 they set themselves up for. No other language expects end-users of the programs written in that language to be sympathetic to some internal engineering transition. All this stuff may have great reasons, but you've already failed if you have to explain those reasons to non-Python users, or tell them this is confirmation bias or whatever. It's just not happening with other languages. And this is for big stuff too. Ansible, which uses 2 pythons, one locally and one remotely, was a pain. Add on to this that this was a fairly public boondoggle, that the makers agree wasn't handled well, so whether "fair" or not, this is a common take away I think.

Post reply on HN