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

471–480 of 513 posts

Re: Python 2 removed from Debian

#471

Post by mikewarot »

waste_monk wrote: post #470
mikewarot wrote: post #469

The comments here seem to break down into 2 camps, who can't understand each other. It would be nice if someone could actually justify the HN position instead of just trying to cancel any dissent. I'm in the minority here on HN, I can't stand the fact that something I use daily on Windows[1] and can continue to do so forever (because it's a compiled program, and the binaries will likely work for decades) can't run th…

>For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day. It is not about fashion, it is about resources and manpower. Supporting Python2 is not free, especially post-EOL, and a huge amount of community effort has gone into supporting it. It is not fair to demand that Debian ensure that vendor-unsupp…

What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023.

I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.

Re: Python 2 removed from Debian

#472

Post by philistine »

orf wrote: post #418
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…

The python2 executable still functions correctly as does all other code you have that relies on python2. Make sure the code is in the right place and run the python executable just as you have done before. However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the ` ` tag and IE 6.0 forev…

alert and blink don't make browsers stop working. They degrade gracefully, just like Pyhton doesn't.

Re: Python 2 removed from Debian

#473

Post by waste_monk »

mikewarot wrote: post #471
waste_monk wrote: post #470

Earlier quoted context omitted.

>For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day. It is not about fashion, it is about resources and manpower. Supporting Python2 is not free, especially post-EOL, and a huge amount of community effort has gone into supporting it. It is not fair to demand that Debian ensure that vendor-unsupp…

What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.

Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was supported in Python2's time this will become an increasing burden.

Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burden.

Python2 has not had a security update since the EOL version 2.7.18. I am not aware of any current CVE's against this version but if one were found Debian would either have to withdraw the package or patch it for any stable versions of Debian. This includes maintaining the build infrastructure for Python2 to be able to patch it if required, bug tracker, etc. as long as Python2 is offered.

> What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023.

I do not have numbers for this, but as the commercial Python2 support I was looking at (Activestate) is "inquire for pricing" I would imagine the equivalent community manpower/resource cost is significant. Just hosting the .deb in the APT repos is cheap - everything else around it is the expensive part.

So it is not so much "the cost of removing it" and more "the cost of keeping it around".

[1] https://www.debian.org/doc/packaging-manuals/python-policy/i...

Re: Python 2 removed from Debian

#474

Post by zarzavat »

IgorPartola wrote: post #273
zarzavat wrote: post #209

Earlier quoted context omitted.

There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years. The print() function was absolutely not worth all the carnage it caused. They could have just kept the print statement around and introduced a printing function with a different name, for example. The fact that they removed syntax for Python 3 meant that all kinds of scientific…

The print function was the simplest part of the transition. For one you could find and replace all instances of it fairly safely across your codebase and you could quickly discover any places where things broke because of a bad replace. That part took like an hour for a large codebase. The Unicode handling on the other hand took ages because string handling is not easily searchable and replacing it requires understan…

Python is a scripting language. Imagine if bash suddenly changed its syntax so that that instead of printing using echo, you now have to write echo(). Sure it’s just a pair of parentheses. But you probably have thousands of shell scripts on your computer. Are you really going to get your hands dirty and risk editing them without knowing what they do?

Of course not, you’re just going to revert back to the version of bash that doesn’t require parentheses and sit on it for as long as you possibly can.

Code exists in three states: actively maintained, done/mature, and obsolete.

Python 3 attacked mature code, forcing developers to either go back into active maintenance or to obsolete it early.

I did transition some Python 2 code to 3. But mostly it was uneconomical and risky, so the vast majority of it sat on Python 2.7 until it was no longer needed.

I feel that most of the people who had a positive experience with Python 3 were people doing webdev using Django. They were working on monolithic actively maintained projects and so transitioning to v3 was just a normal maintenance activity.

Re: Python 2 removed from Debian

#475

Post by codebje »

patrakov wrote: post #150
codebje wrote: post #34

Earlier quoted context omitted.

You don't need to expunge c89 from gcc for progress to have happened - we've got c99 and c11 and whatever c17 is or isn't already there. Effectively, however, python2 and python3 are different languages. Since they're interpreted, there's now a problem with '#!/usr/bin/env python' in your script: which python version is being invoked? Which language version are modules targeting? It's a mess. But the poster child for…

At least they kept the old version and thus didn't screw up others.

Yes, that's true - I may have to reconsider which one I think got it the most wrong :-)

Re: Python 2 removed from Debian

#476

Post by mikewarot »

waste_monk wrote: post #473
mikewarot wrote: post #471

Earlier quoted context omitted.

What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.

Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was supported in Python2's time this will become an increasing burden. Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burd…

So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4.

The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it?

Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be able to run any random program in a safe and secure manner, no matter how evil it is.

It's the lack of capability based security that is the real problem with Linux.

Re: Python 2 removed from Debian

#477

Post by kelipso »

I can't wait for Python 4 to come out and millions of lines of Python 3 that will be written this year get trashed and rewritten after they declare a bunch of useless incompatible changes again.

And of course cue the endless lines of fanboys screaming get used to the new reality, rewrite everything to Python 4 cus Python 3 is EOL and gone folks!

Re: Python 2 removed from Debian

#478

Post by waste_monk »

mikewarot wrote: post #476
waste_monk wrote: post #473

Earlier quoted context omitted.

Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was supported in Python2's time this will become an increasing burden. Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burd…

So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4. The idea of having to test a language seems weird , either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be…

>as this is likely to happen again with Python 4

Apparently there will be no Python 4 [1].

>The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it?

Sorry if this was not clear - not testing the language (although you'd need to make sure the standard library works properly for anything with C bindings), but that the interpreter runs properly under each new version of the Debian operating system.

Debian would have to build and package the Python2 binary and related stuff from upstream. There are no Python2 vendor-supplied Linux binaries or deb packages. Officially continuing support would also include having to provide patches in case of security issues etc., fixing any breakage (I'm not sure what Python depends on but I have had friends suffer breakage between versions of Debian with newer versions of glibc and so on), etc.

>Also, why does an interpreter need security updates?

Things like this issue in Python's sockets library[2]:

"Buffer overflow in the socket.recvfrom_into function in Modules/socketmodule.c in Python 2.5 before 2.7.7, 3.x before 3.3.4, and 3.4.x before 3.4rc1 allows remote attackers to execute arbitrary code via a crafted string. "

There have been a number of vulns for Python itself over the years [3]. Not aware of any for the last version of Python2 but that may be simply for lack of attention given it's EOL and in theory everyone should have migrated to Python3 by now.

>You should be able to run any random program in a safe and secure manner, no matter how evil it is.

>It's the lack of capability based security that is the real problem with Linux.

Perhaps, and things like SELinux help, but it does not change the reality that someone has to maintain the software when these issues do show up.

[1] https://www.techrepublic.com/article/programming-languages-w...

[2] https://www.cvedetails.com/cve/CVE-2014-1912/

[3] https://www.cvedetails.com/version-search.php?vendor=Python&...

Re: Python 2 removed from Debian

#479

Post by mikewarot »

waste_monk wrote: post #478
mikewarot wrote: post #476

Earlier quoted context omitted.

So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4. The idea of having to test a language seems weird , either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be…

>as this is likely to happen again with Python 4 Apparently there will be no Python 4 [1]. >The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Sorry if this was not clear - not testing the language (although you'd need to make sure the standard library works properly for anything with C bindings), but that the inte…

>things like SELinux help

The problem is that SELinux is not an implementation of capabilities based security, despite appearances.

Re: Python 2 removed from Debian

#480

Post by mikewarot »

jasonmp85 wrote: post #464
tolmasky wrote: post #353

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…

The point is just you don’t understand how your tools work.

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.

Post reply on HN