Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

281–290 of 513 posts

Re: Python 2 removed from Debian

#281

Earlier quoted context omitted.

> Migration path was unnecessarily difficult as was compatible code. I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consi…

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?

Re: Python 2 removed from Debian

#282
post #231

I really feel like the community was a difficult pain in the ass during the 2->3 migration. There were breaking changes but I’m sure the Python maintainers didn’t expect the community to react so badly. Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.

The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community. A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example. The list of stuff that got…

> The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community.

The other side of that coin is that the python maintainers went out of their way to push back the Python 2 EOL. They kept on pushing the date back and back again, as per the sunset page:

"We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020."

The drawn out demise of Python 2 was, frankly, painful.

I have no time for whinging snowflakes complaining 12 years (2020-2008) was not enough time to migrate their code to Python 3. Hell, even the original 7 years (2015-2008) should have been long enough for 99.999999% of the community.

Re: Python 2 removed from Debian

#283

Earlier quoted context omitted.

> Migration path was unnecessarily difficult as was compatible code. I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consi…

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.

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 deprecation for how long? A decade?

You're fabricating problems where there are none.

> Your comment is a perfect illustration of the issues. Lots of user blaming.

There is no issue. When I had to port projects to Python3, I just ported them. No drama, no hangup. You're pretending there were problems where there were none, and you're throwing a tantrum when this fact is pointed out to you.

There is really no justification for this. It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes.

Some projects were rewritten from scratch in entirely different tech stacks in less time the likes of you complained they could not update their projects from python2 to python3.

Re: Python 2 removed from Debian

#284

Earlier quoted context omitted.

> there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact). (Seems like a lot of people are using system Python, which isn't really recommended.)

Yeah, I have no problem running stuff from a decade ago because of virtual env and pip freeze (even across diff oses).

I have no problem running stuff from a decade ago either on the same box and installation that it was on a decade ago. But virtual environments and pip freeze are closer to mothballing an old box than displaying long term code compatibility and functionality. Their main reason to exist is as a workaround precisely because there are such issues.

The whole idea that you need a multitude of environments to support applications written in the same interpreted language is where it breaks, that should not have been necessary if backwards compatibility had not been an issue.

Re: Python 2 removed from Debian

#285

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?

This was the issue. Why should a new version make it hard to run old code for no particular reason except to break things.

Folks using u”” were already being careful with Unicode . Supposedly Unicode was important enough for 3 to default to it.

The cost benefit of then destroying code using u”” made no sense to me. It was unnecessary. This was followed by the oh just upgrade thing. I’d love to see the “quick” upgrade guidos employer did. My guess is a total lie that it was easy and it probably took years and VC type money.

It’s not about using new features, it’s about not unnecessarily breaking old or allowing for cross compatibility.

Re: Python 2 removed from Debian

#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 it something else that wants Python 2 starts complaining. You have containers that have worked for years that all of a sudden error out saying "Python 2 is no longer supported," and you have to dig up whatever library or utility that would otherwise work fine has some sort of date-based check or something? I don't know, all I know is a compiled C++ thing works the same yesterday as it does today, and I can upgrade on my timeline, not have a random Docker layer cache invalidation result in a week's worth of Python 3 migration in the least important part of my build. And it keeps happening, again, because this is not in stuff I directly edit, it's all in random dependencies and sub-utilities of utilities I install. So it is non-trivial to even go in with the mindset of "I will update everything on our systems that use Python". Although I guess if it's being pulled completely now that job will once again be done for me. Sigh.

I have this opinion about no other language. I am generally neutral about languages I don't use. But literally my only experience with Python is porting to Python 3. It's like a sitcom scenario of how to force the worst possible first impression for a language ever. The amount of slowdown and pain that Python 3 has generated on our non-Python project is really just out of this world ridiculous.

Re: Python 2 removed from Debian

#287

Earlier quoted context omitted.

The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community. A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example. The list of stuff that got…

> Migration path was unnecessarily difficult as was compatible code. I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consi…

So why did for example Ruby not have such a painful transition from 1.8 to 1.9/2.0? My theory is that the Ruby people make the migration in many steps, it started even back in at least Ruby 1.8.6 and they did it with a lot of care on how to make the transition as painless as possible while the Python team just broke everything and bet on that tools like 2to3 would just magically solve it.

Re: Python 2 removed from Debian

#288

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

Anyways - they did eventually get a clue. It’s much easier NOW to handle this, but it wasn’t at the start. Yes, they did put u”” back in. No it did not destroy the world.

Re: Python 2 removed from Debian

#289

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?

> using features that don't exist in an older version

Except they broke the old way for existing features, required you to use the new way and in most cases you could manually write code so it would still work with both. Meanwhile the only tooling provided by the python 3 crowd screwed over anyone with an existing customer base stuck on python 2, which at least early on should have been a foreseeable problem. Not to forget that anyone stuck on python 2 was literally Satan and projects where outright "shamed" to drop python 2 support.

Re: Python 2 removed from Debian

#290
post #287

Earlier quoted context omitted.

> Migration path was unnecessarily difficult as was compatible code. I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consi…

So why did for example Ruby not have such a painful transition from 1.8 to 1.9/2.0? My theory is that the Ruby people make the migration in many steps, it started even back in at least Ruby 1.8.6 and they did it with a lot of care on how to make the transition as painless as possible while the Python team just broke everything and bet on that tools like 2to3 would just magically solve it.

Right. I think a key miss was underestimating value of code that would work w both 2 and 3. This avoids need to upgrade all at once.

Relax things a tiny bit in 3, back port to 2 via futures, get a library like six going. It could have been a ton easier.

In fairness by 3.5 maybe they’d realized this, but a lot of lecturing was done before. Initially recommendation was to upgrade all dependencies and programs to 3 and not try and make dependencies work w both

Post reply on HN