9 ms·

Python 2 removed from Debian

471 points by zdw 4y ago

deleted 4y ago
[deleted]
mikewarot 4y ago
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 the same code in Linux, where the source is in python, and both it and wx_windows have made breaking changes. 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 would be like declaring all HEX wrenches and tools to be obsolete one day, and insisting that everything was either 7 sided or heptalobe instead, for "reasons" It seems completely irrational that Python 2 is excluded. This isn't like a web site where there is an active party supporting the other end, this is code written in a language that had risen to popularity based on how well it was supported. And that support has been arbitrarily withdrawn, and the HN crowd seems to cheer it on. I submit that this is part of why the year of the Linux Desktop just keeps receding into the future. [1] https://wikidpad.sourceforge.net/ https://wikidpad.sourceforge.net/
- waste_monk 4y ago
  >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-unsupported legacy software continue working indefinitely, especially given the environment it would be running on is a moving target that will only diverge further from what was contemporary with Python2 with each release. >This isn't like a web site where there is an active party supporting the other end This is exactly like that. The "active party" in this case just happens to be the Debian community. If you wish to continue using Python2, either stick to running it on an outdated environment such as Debian Buster that supports it natively (and accept the security consequences of doing so), take on the burden of porting it to modern Debian yourself, or seek out one of the commercial support options that exist for post-EOL Python2. You are not entitled to indefinite free labour.
  - mikewarot 4y ago
    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.
    - waste_monk 4y ago
      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/index.html#unversioned-python-commands https://www.debian.org/doc/packaging-manuals/python-policy/i...
      - mikewarot 4y ago
        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.
kelipso 4y ago
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!
josephcsible 4y ago
3 years after going EOL, and 14 years after the release of Python 3. Good riddance at long last.
- chungy 4y ago
  I suspect that Debian 10 and 11 will continue getting security patches for some time. All the same, it's great progress. :)
  - captn3m0 4y ago
    Debian 11 goes EOL in August 2026.
    - chungy 4y ago
      It's pretty bold to pin such a specific date when the release date of Debian 12 is not yet known. Debian releases are fully supported for one year after the next release launches, and then the LTS projects keep it going for another 5~7 years.
      - captn3m0 4y ago
        True, should have said "around Aug 2026" perhaps? The LTS project[0] plans for a minimum of 5 year support from the date of initial release, so Aug 2026 is based on the Aug 2021 release date + 5 years. The rough-schedule on the LTS wiki also uses "June 2026" for now. That's what we've been showing so far on https://endoflife.date/debian https://endoflife.date/debian (With a disclaimer about what LTS means). Suggestions welcome! [0]: https://wiki.debian.org/LTS https://wiki.debian.org/LTS
- cellularmitosis 4y ago
  I see the sort of perspective pervasively, but I don’t really understand it. I would guess that most people wouldn’t consider expunging c89 from gcc to be progress, yet this is almost universally the attitude towards python2. What am I missing?
jacquesm 4y ago
And not a decade too soon. The Python 2 -> Python 3 migration will be studied for a long time as an example how not to release a new version of your language or library, right next to that Angular thingy. The number of headaches I've had to deal with because of this over the years have just about soured me on the whole Python offering, and I used to be a pretty big fan. Great that Debian finally pulls the plug on it, that means that most if not all of the downstream distros (such as Ubuntu) will probably follow suit, that's a big fraction of the whole Linux eco-system.
- deleted 4y ago
  [deleted]
- logicallee 4y ago
  Yes, it is nice to see the python 3 migration is pretty much done, it really could have happened literally a decade ago! While we're all here: which is the package manager to use?
  - anttihaapala 4y ago
    > which is the package manager to use? pip
    - dharmab 4y ago
      My team is using Poetry. Did you know pip can execute arbitrary code when installing packages?
      - teruakohatu 4y ago
        I use poetry but regardless as soon as you import a library arbitrary code is executed.
      - matusf 4y ago
        [dead]
      - 4y ago
nibbleshifter 4y ago
print "goodbye, sweet prince" I've been slowly porting a lot of my legacy code from 2 to 3 on an as-needed basis, there's a few bits though that are just too huge/crusty/etc that they will never get ported.
- bmitc 4y ago
  Doesn't this say something about the language if it's been so difficult for people to migrate from 2 to 3? Yes, it was a major version change, but it doesn't bode well for arguments that Python is a good language to do long-term, maintainable, and large-scale development. Sure, now things are "settled" with 3, but Python continues to get more features. It just doesn't look good for the language if even doing a language version migration was a literal brick wall for so much of the community.
  - jacquesm 4y ago
    Let me be blunt here: Python sucks, but that's at the level of 'programming languages people complain about and programming languages nobody uses'. However the Python libraries absolutely rock and the ease with which you can get really performant number crunching code out of what is nominally an interpreted language is amazing. Statistics, machine learning, engineering, the notebooks etc, I would not pick anything else for work like that, it's a near infinite box full of powertools. But it would be a mistake to consider Python anything but luxury glue no matter how much you've used it for production code, it isn't and never will be a bullet proof language, there are just too many ways in which the runtime can surprise you and the long term maintainability of any Python codebase is always going to be questionable, in part because you will most likely have dependencies on stuff that will silently disappear or change out from under you while you're not watching. I've been writing Python code pretty much since it was first released and 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. This as opposed to just about every other language that I've used, which I find very frustrating because Python could be just about perfect. And I'm still sore about significant whitespace ;)
    - 4y ago
deleted 4y ago
[deleted]
pyuser583 4y ago
I feel like I should cry.
killjoywashere 4y ago
I feel like there was a batch of big software from the 90s and early 2000s that took a really long time to die, and they're not necessarily dead yet: Windows XP. Java. Python 2. IPv4. X11. Free/Open/NetBSD (1). Hell, I was using (adding new data to) a MUMPS-based system on OpenVMS until 2018. But I feel like we are seeing fewer new widely-publicized death marches now, despite many more projects starting. What changed in the community? What lesson was learned? It seems like a weird corollary of the Streisand Effect: if you announce something's EOL, you'll get more clingy users that keep the product out of the grave, creating a drag on maintenance budgets, but, maybe, if you just stop maintaining and walk away, dependent users will either notice and switch away, or die themselves, and the death will ultimately be quicker and quieter. (1) As an example: https://news.ycombinator.com/item?id=26168596 https://news.ycombinator.com/item?id=26168596
- LAC-Tech 4y ago
  (1) As an example: https://news.ycombinator.com/item?id=26168596 https://news.ycombinator.com/item?id=26168596 LOL that's an ancient bit of copy pasta. Here's a page from over two decades ago that was already describing it as a "classic troll". https://everything2.com/title/BSD+is+dying https://everything2.com/title/BSD+is+dying
- guidedlight 4y ago
  Java?
- BossingAround 4y ago
  Java is live and well, still one of the most popular languages today.
- jacquesm 4y ago
  MUMPS... arrrrggghhhh.... instant outbreak of skin rash and stress just from hearing the name. Thank you. ;) Seriously though, that was one interesting language, the number of weird features (the editor is a string) that you'll come across in MUMPS make it fascinating just to study and wonder what inputs into the decision making process around the design trade offs were.
- 4y ago
nigamanth 4y ago
I remember using Python 2, if not for Python 3 it would've never become as big as it is today tbh. Been long enough for everyone to migrate to python3, and this finally happened.
- latenightcoding 4y ago
  Doubt this. Many of the libraries that made python so popular were born in Python 2. e.g: most ml and scientific computing libraries still used today.
whirlwin 4y ago
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 again, please.
- lifthrasiir 4y ago
  > 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 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. [1] https://github.com/python/cpython/tree/main/Lib/lib2to3 https://github.com/python/cpython/tree/main/Lib/lib2to3
  - kasabali 4y ago
    > first major language with this approach was ECMAScript 2009 (5th ed.) Not that I've any proof but I kind of find it hard to believe there were no other examples before
    - TJSomething 4y ago
      Perl's original "use strict" was added in 1994 with Perl 5, to allow backward compatibility with Perl 4 scripts.
    - masklinn 4y ago
      Python had that long before js, with __future__ imports. But editions & friends are for syntax. Python 3 changed semantics all around. Editions are not an option when you’re changing the langage’s entire text model, especially without static typing.
potamic 4y ago
And as we speak, I upgrade to 3.10 only to see my dependencies break and wonder if they have learnt anything at all.
- thomasahle 4y ago
  I don't think there are any breaking changes in Python 3.10? Sounds more like a package management issue.
  - qwertox 4y ago
    Depending from which version you're upgrading from. I think there are breaking changes between 3.7 (or 3.8?) and 3.10 regarding the asyncio loop. I had (simple) servers cause exceptions because they used `loop` as a keyword argument which got removed without proper deprecation.
  - jjluoma 4y ago
    At least they removed something that had been deprecated ERROR: gcloud failed to load: module 'collections' has no attribute 'Mapping'
    - EdwardDiego 4y ago
      That was a 3.8 change I think? It moved from collections to collections.abc, IIRC.
      - Beltalowda 4y ago
        In the 3.9 release notes it says "Aliases to Abstract Base Classes in the collections module, like collections.Mapping alias to collections.abc.Mapping, are kept for one last release for backward compatibility. They will be removed from Python 3.10" but the 3.10 release notes don't really mention it. Apparently it's been emitting a DeprecationWarning since Python 3.3 (2012), but still... I like to have things "just work" even if I return to them after 5 or 10 years.
tgsovlerkhgsel 4y ago
Glad this is finally mostly over, but... that was bad. I wonder if the energy that had to be put into this migration by everyone involved was worth what seems to be relatively small improvements. The print-as-a-statement was ugly but convenient and didn't seem like a big deal, the integer division was something that you could live with once you knew about it (and you still need to know what the current behavior is), and the new string types make code more verbose, and the way they were handled introduced countless hard to find bugs during the migration.
- gspetr 4y ago
  IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013): https://www.youtube.com/watch?v=f_6vDi7ywuA https://www.youtube.com/watch?v=f_6vDi7ywuA
  - p-e-w 4y ago
    > "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then maybe it would have been. As it stands, Python's biggest weaknesses remain unaddressed.
    - EdwardDiego 4y ago
      > The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. That's reading far too much into a tongue in cheek presentation title. Besides, good devs are typically reasonably skeptical of new and shiny. And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment. Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features. And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.
yieldcrv 4y ago
Good riddance
_8j50 4y ago
This really sucks but at least pyenv exists. Basically distros care so little about their users we have to use external tools to use python2. "Everyone has has a chance to migrate" . Doesn't work that way, just yesterday I spent a few hours trying to get scripts that are really good and would take me forever to migrate that are in python2 to work on an ubuntu based distro and this is with pyenv, custom venv,etc... just when you get python syntax worked out you are faced with deprecated or uselessly renamed imports and modules. This is the shitty aspect of using foss stuff. I don't pay for it so I have to accept their decission. But in the broader sense, inability to influence things like this even with a ton of other people willing to pay for it is frustrating. You know what would be great? If the community can vote with money pledges. So it you have 1000 people willing to donate $10/month to support python on sysv init then if volunteers don't want the money we get an external person getting paid 10k/month to support these packages even if the corporate types, developers and "devops"/sysadmin people have no use for it. The free part of foss is expensive but I think the middle ground is to collectively pay for the support. I try very hard to avoid python2, I am not a developer and I very easily lose at least 1h/month on average to resolve these issues. Do you all know why 2023 will not be the year of the Linux desktop? Because desktops are a commercial market and consumers/users cannot sway what the Linux desktop experience is. They either accept things as they are or pay for them by spending time reporting bugs, troubleshooting stuff, asking questions on random sites,etc... a lot of this has to do with change and maintenance requiring human time and resources. It's great when there are no issues and volunteers donate their time but it would be great to be able to pay with money also to support features or resolve issues. You can even make sure multiple people pay an equal amount to avoid wealthy people having too much or an influence but it still will not affect regular volunteer work. I was hoping Ubuntu and Fedora would have such features.
- yjftsjthsd-h 4y ago
  > Do you all know why 2023 will not be the year of the Linux desktop? Because desktops are a commercial market and consumers/users cannot sway what the Linux desktop experience is. And... you believe that Microsoft and Apple are swayed by users? More than Red Hat and Canonical? I don't buy that for one second.
qwertox 4y ago
I liked how Canonical did it: the command `python` would not execute, you have to use `python3` explicitly. This means that your old Python 2 code would not get executed if it were triggered by some shell script via the `python` command, you'd have to fix the shell script and become aware that you still need to migrate the Python script.
- orangepanda 4y ago
  I dont know python. Does python3 have different behaviour than python2 on the same code, beyond just crashing?
  - mau 4y ago
    You can write code that runs in both interpreters. Same syntax can have different behavior. I guess nowadays, as the py2 compatibility is a thing of the past, most programs would crash when using that interpreter version.
  - Tom4hawk 4y ago
    Integer division
- bayindirh 4y ago
  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.
  - ilyt 4y ago
    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
Flimm 4y ago
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!
- thrdbndndn 4y ago
  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 bytes. I mean, it of course has its upside, but I don't think it's worth it if you care even slightly beyond ASCII.
  - mrweasel 4y ago
    We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief. Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017.
    - Jenda_ 4y ago
      > Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017. For example GnuRadio started supporting Python 3 with GnuRadio 3.8 released in 2019, and then you had to port all your programs using it to this version. So no, in 2017, the ecosystem was not ready.
    - 4y ago
psychphysic 4y ago
2to3 really showed that Python didn't understand their audience. If they had started a new project called COBRA and just eventually had it over take python the world would be all over it. But massive breaking changes going from 2 to 3 was a disaster for their audience. Worse still you could hear the acrimony in Pythons communications on the topic.
- groestl 4y ago
  I'm wondering, is there work on how python 3's changes could have been promoted in smoother way?
  - EdwardDiego 4y ago
    An excellent question, how do you smoothly break compatibility?
    - tormeh 4y ago
      Really annoying deprecation notices help a bit.
    - broeng 4y ago
      I think two aspects have played a significant part in the migration pain: 1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable. 2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI. Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
      - peterfirefly 4y ago
pjmlp 4y ago
Meanwhile we are still living our Python 2 like moments in .NET and JVM ecosystems, with the huge amount of projects stuck in .NET Framework and Java 8, with no end in sight of them ever moving forward.
- matsemann 4y ago
  It's not as big of a deal, though. Code written for java8 is still source backwards compatible on newer platforms. And in .net/jvm you're not depending on some interpreter on the OS level and don't have code bundled with the OS, as has been the big issue with lots of small python scripts included in various distros.
  - pjmlp 4y ago
    On .NET Framework you surely depend on OS integration, that is one of the major design changes in .NET Core. Starting with Java 9, finally the long deprecated APIs started to be removed. In any case, the issue is that we are forced to write C# 7 and Java 8 code. Some well known examples, Sitecore, SharePoint WebParts, SQL Server SP extensions, Dynamics, Office AddIns, VS plugins, Solr extensions (many places keep using Solr on Java 8 even if more recent versions exist), Android (unless one goes Kotlin or targets version 12), Forms and WPF 3rd party components (the versions on .NET Core are incompatible due to new designer)...
- mnau 4y ago
  Yeah, I hoped MS would be more supportive of .NET Standard 2.0 during transition period. I am stuck on .NET48 at least for another two years (because of webforms frontend) and the last version of EF Core that supports .NET Standard 2.0 is 3.1. They dropped .NET Standard 2.0 like a rock... for what? Few default interface implementations. Or nullability attributes that are missing in .NET Fx, they could also be defined externally, like R# does. Nope, sucks to be you.
- was_a_dev 4y ago
  My previous, and only, software developement job involved migrating a monolithic .NET Framework web app to .NET 5.0 Compared to Python 2->3, the breaking changes were more obvious as they involved entire strucutres and paradigms being deprecated. Python 2->3 felt a lot more subtle despite being just as damaging.
sherr 4y ago
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 support ends. I'd rather not have to have another VM though.
- rc00 4y ago
  I had a VM with MediaWiki way back when and I was able to convert it to markdown and a private GitHub repository pretty easily with pandoc. I'm not familiar with Moin Moin but maybe there's a conversion tool you can use to do the same thing?
- oefrha 4y ago
  Just make a container for it and you can run as many of them as you like without VM overhead.
- dvdkon 4y ago
  MoinMoin2 exists and works on Python 3, but sadly there's still no stable release and it requires slightly older Python packages right now. We've also had strange problems with index (Whoosh library) performance on a large wiki that we had to hack around, but it might be a good migration path for you. And if you don't want to use moin2, it can convert the custom markup to Markdown, which you can then use elsewhere.
- solarkraft 4y ago
  What shocks me is that MoinMoin doesn't support Python 3.
  - Beltalowda 4y ago
    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 https://moinmo.in/MoinMoin2.0 anyway.
andrewstuart 4y ago
It craps me off that I still need to look up which direction to encode/decode strings and other things like bytes and ascii even after programming Python 3 for more than 10 years. It's a huge usability fail on the part of Python that it's not obvious and easily memorable how to do this.
- maxbond 4y ago
  You encode strings to bytes, you decode bytes to strings. A string is an abstract representation of text, which can be encoded into whatever supported format you'd like; bytes are a concrete representation of binary data, such as text encoded in UTF8, which, if it represents text, can be decoded to obtain a string. If you think about it, that's the only way that makes sense; if you wanted to go from, say, UTF8 to UTF16, you'd need to have an intermediate step that was abstract and formatless. Similarly, when you're operating on text, you don't want it to have a particular format; the format should only exist at the edges, where you take text in and output it. The format is a way to communicate with other programs, not components within your program. My advice would be, if that doesn't stick in your head (totally legitimate), write down a code example and stick it in a personal wiki or something. I find it really helps me to understand something once and more or less copy paste it forever.
  - andrewstuart 4y ago
    I understand the reasons, it’s Python's fault that it’s not easy to remember and program. This is a key reason why people hated Python 3 so much IMO. For context I’m a huge advocate of Python 3, except for this (and lambda functions, but that’s another whine session).
- saila 4y ago
  It's not that complicated nor is it a Python specific issue. This is a good article on the topic: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ https://www.joelonsoftware.com/2003/10/08/the-absolute-minim... A simplistic summary is that you always decode to unicode and always encode to bytes. Another way to think about it is that Unicode is an idealized character model that is reified into a byte encoding, usually UTF-8, for practical usage. It seems to me that this is something a lot of developers don't think too much about until they run into some obscure encoding/decoding issue, but it's kind of a fundamental aspect of programming that's worth spending some time grokking.
bad-engineers 4y ago
KILL IT WITH FIRE
- mikewarot 4y ago
  Yes, Kill PYTHON3 with Fire, end this stupid unicode fetish!
w4rh4wk5 4y ago
Congratulations! Guess we finally managed to move on :)
bb88 4y ago
Good.
willis936 4y ago
Reminder that python 2 was liked once. https://xkcd.com/353/ https://xkcd.com/353/
mikewarot 4y ago
I can't use Linux as a daily driver because of the Python 2/3 breaking change. My personal wiki (WikidPad) just doesn't work properly under linux due to the changes that happened in Python and then wxWindows. There are ports that barely work, but all the dialog boxes to adjust anything just error out. It's really sad that the Python folks committed suicide this way, all over a unicode fetish.
nmstoker 4y ago
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.
- rpep 4y ago
  I worked on a code base which had a large dependency not port to Python 3 until 2018, and at the same time they made a huge ton of changes to the APIs, most of which were not documented well. So there was both a big refactoring to handle binary data transfer between it and the application, and also a ton of other unrelated things just to make it work. It's things like that that made it difficult to port for most people.
- hnfong 4y ago
  The lack of type checking and general runtime failures made the transition particularly difficult if you didn't have a bazillion unit tests covering all your large codebases. I was lucky it didn't affect me much, but I could sympathize if somebody had hundreds of thousands of lines of python2 legacy code that needs to be migrated..
thiht 4y ago
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.
- pjc50 4y ago
  > Are there some valid reasons that made 2->3 migration insanely hard for some projects? Print was a non-issue once you could do "from __future__ import print_function". It was the unicode migration. All string handling from I/O required at least checking. The dependency issue was the most crippling, though: because you can't load Python 2 code from Python 3, before your project can begin migrating you have to wait for all your dependencies to update as well. This may involve them changing the types that get passed over the API from 'str' to 'bytes' or vice versa, which is potentially a breaking change.
  - nonethewiser 4y ago
    Sounds like a circular problem
- MereInterest 4y ago
  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 case applies. For python2, the str class could either contain a sequence of characters, or could contain a sequence of bytes. These are often conflated when using ASCII encoded text, but are very different for any other encoding. In python3, these are represented by the str class for a sequence of characters, and by the bytes class for a sequence of bytes. It’s so much nicer to work with, but required manually separating out the earlier use case.
sovietmudkipz 4y ago
When (if?) the dust settles, I'd love to watch a technology focused documentary to hear the historic retelling of all the python 2 to 3 events. It started before I started programming, I don't program in python much, and thus I don't have a ton of context. If anyone has any good resources I could browse that might help me understand the full story feel free to share.
- pnt12 4y ago
  My 2 cents: I learned python 2 in 2015 or so because I was recommended "Learn python the hard way", whose author defended python2 with a passion. So I started with python 2 and found the book crap. The author's idea of teaching is telling others to repeat an exercise a hundred times with all possible variations. There were more than a dozen about printing stuff to a terminal, before you got into any interesting stuff. From their website, although they added a new course and book for python 3, they are still selling the ones for python 2. Still selling stuff for a version killed 3 years ago requires some fucking audacity. Later I learned python 3 from other source and loved it. It's what I mostly program with today.
tolmasky 4y ago
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.
- Apofis 4y ago
  I just avoid Python and any job descriptions that contain it. It's never been a good experience for me, whether as an end user or a developer. It's nice that they may have ironed out their issues, but I've been done a long time ago. There's nothing Python does I can't do better with some other toolchain.
- Waterluvian 4y ago
  I’m curious why installing Python 3 causes Python 2 programs to break. The only reason I can come up with is that the installation process is wrongly changing the `Python` symlink. Anyone have other known causes? Does it screw with dependencies?
nano9 4y ago
I welcome Python3 just fine. Character data no longer being automatically ASCII might be a bit annoying, but it's fine if that's what it takes to support a more global developer base. I just wish they would stop iterating on the minor version so quickly. Why are we on python 3.11 (for workgroups, just kidding)? Is there that much of a difference compared to 3.7? 3.7 even has dicts with stable key insertion order and type hinting, so it seems pretty loaded if you ask me.
- pistolpeteDK 4y ago
  I don't think we'll see a version 4 for the next decade or so (because of the python3 debacle) - so it'll probably just be various improvements to the standard library. There's a lot of improvements being made to Python on these minor versions. So while the version bump looks minor, they can make quite a big impact. 3.11 improved performance by 25-60% (depending on use-case). 3.12 is set to improve performance yet again (Special thanks to Mark Shannon, GvR and Microsoft). On top of that there's a lot of quality-of-life improvements for the various parts of the std.lib. I like this apporach very much, since upgrading to a new minor Python version is somewhat trivial
  - Izkata 4y ago
    Performance improvements without changes to the interface seems like it should have been 3.11.1; were there other changes?
- mort96 4y ago
  Were strings in Python 2 really only ASCII? I was sure you could put UTF-8 data in Python 2 strings?
at_a_remove 4y ago
I'm in an extremely weird, one-off position (a chain of interesting dependencies) where I am still on Python 2.7. Not sure when we'll be able to move to a newer version but it sounds like a lot of the growing pains have been dealt with. It should be interesting, most of my inputs are still in ASCII-land. (I know someone who will pretend to know my situation better than I will advocate for some "solution;" no, it won't work in a way that won't break some of my priors)
hartator 4y ago
print "sad"

471 points by zdw 4y ago

deleted 4y ago

[deleted]

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 the same code in Linux, where the source is in python, and both it and wx_windows have made breaking changes. 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 would be like declaring all HEX wrenches and tools to be obsolete one day, and insisting that everything was either 7 sided or heptalobe instead, for "reasons" It seems completely irrational that Python 2 is excluded. This isn't like a web site where there is an active party supporting the other end, this is code written in a language that had risen to popularity based on how well it was supported. And that support has been arbitrarily withdrawn, and the HN crowd seems to cheer it on. I submit that this is part of why the year of the Linux Desktop just keeps receding into the future. [1] https://wikidpad.sourceforge.net/ https://wikidpad.sourceforge.net/

waste_monk 4y ago
>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-unsupported legacy software continue working indefinitely, especially given the environment it would be running on is a moving target that will only diverge further from what was contemporary with Python2 with each release. >This isn't like a web site where there is an active party supporting the other end This is exactly like that. The "active party" in this case just happens to be the Debian community. If you wish to continue using Python2, either stick to running it on an outdated environment such as Debian Buster that supports it natively (and accept the security consequences of doing so), take on the burden of porting it to modern Debian yourself, or seek out one of the commercial support options that exist for post-EOL Python2. You are not entitled to indefinite free labour.
- mikewarot 4y ago
  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.
  - waste_monk 4y ago
    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/index.html#unversioned-python-commands https://www.debian.org/doc/packaging-manuals/python-policy/i...
    - mikewarot 4y ago
      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.

kelipso 4y ago

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!

josephcsible 4y ago

3 years after going EOL, and 14 years after the release of Python 3. Good riddance at long last.

chungy 4y ago
I suspect that Debian 10 and 11 will continue getting security patches for some time. All the same, it's great progress. :)
- captn3m0 4y ago
  Debian 11 goes EOL in August 2026.
  - chungy 4y ago
    It's pretty bold to pin such a specific date when the release date of Debian 12 is not yet known. Debian releases are fully supported for one year after the next release launches, and then the LTS projects keep it going for another 5~7 years.
    - captn3m0 4y ago
      True, should have said "around Aug 2026" perhaps? The LTS project[0] plans for a minimum of 5 year support from the date of initial release, so Aug 2026 is based on the Aug 2021 release date + 5 years. The rough-schedule on the LTS wiki also uses "June 2026" for now. That's what we've been showing so far on https://endoflife.date/debian https://endoflife.date/debian (With a disclaimer about what LTS means). Suggestions welcome! [0]: https://wiki.debian.org/LTS https://wiki.debian.org/LTS
cellularmitosis 4y ago
I see the sort of perspective pervasively, but I don’t really understand it. I would guess that most people wouldn’t consider expunging c89 from gcc to be progress, yet this is almost universally the attitude towards python2. What am I missing?

jacquesm 4y ago

And not a decade too soon. The Python 2 -> Python 3 migration will be studied for a long time as an example how not to release a new version of your language or library, right next to that Angular thingy. The number of headaches I've had to deal with because of this over the years have just about soured me on the whole Python offering, and I used to be a pretty big fan. Great that Debian finally pulls the plug on it, that means that most if not all of the downstream distros (such as Ubuntu) will probably follow suit, that's a big fraction of the whole Linux eco-system.

deleted 4y ago
[deleted]
logicallee 4y ago
Yes, it is nice to see the python 3 migration is pretty much done, it really could have happened literally a decade ago! While we're all here: which is the package manager to use?
- anttihaapala 4y ago
  > which is the package manager to use? pip
  - dharmab 4y ago
    My team is using Poetry. Did you know pip can execute arbitrary code when installing packages?
    - teruakohatu 4y ago
      I use poetry but regardless as soon as you import a library arbitrary code is executed.
    - matusf 4y ago
      [dead]
    - 4y ago

nibbleshifter 4y ago

print "goodbye, sweet prince" I've been slowly porting a lot of my legacy code from 2 to 3 on an as-needed basis, there's a few bits though that are just too huge/crusty/etc that they will never get ported.

bmitc 4y ago
Doesn't this say something about the language if it's been so difficult for people to migrate from 2 to 3? Yes, it was a major version change, but it doesn't bode well for arguments that Python is a good language to do long-term, maintainable, and large-scale development. Sure, now things are "settled" with 3, but Python continues to get more features. It just doesn't look good for the language if even doing a language version migration was a literal brick wall for so much of the community.
- jacquesm 4y ago
  Let me be blunt here: Python sucks, but that's at the level of 'programming languages people complain about and programming languages nobody uses'. However the Python libraries absolutely rock and the ease with which you can get really performant number crunching code out of what is nominally an interpreted language is amazing. Statistics, machine learning, engineering, the notebooks etc, I would not pick anything else for work like that, it's a near infinite box full of powertools. But it would be a mistake to consider Python anything but luxury glue no matter how much you've used it for production code, it isn't and never will be a bullet proof language, there are just too many ways in which the runtime can surprise you and the long term maintainability of any Python codebase is always going to be questionable, in part because you will most likely have dependencies on stuff that will silently disappear or change out from under you while you're not watching. I've been writing Python code pretty much since it was first released and 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. This as opposed to just about every other language that I've used, which I find very frustrating because Python could be just about perfect. And I'm still sore about significant whitespace ;)
  - 4y ago

deleted 4y ago

[deleted]

pyuser583 4y ago

I feel like I should cry.

killjoywashere 4y ago

I feel like there was a batch of big software from the 90s and early 2000s that took a really long time to die, and they're not necessarily dead yet: Windows XP. Java. Python 2. IPv4. X11. Free/Open/NetBSD (1). Hell, I was using (adding new data to) a MUMPS-based system on OpenVMS until 2018. But I feel like we are seeing fewer new widely-publicized death marches now, despite many more projects starting. What changed in the community? What lesson was learned? It seems like a weird corollary of the Streisand Effect: if you announce something's EOL, you'll get more clingy users that keep the product out of the grave, creating a drag on maintenance budgets, but, maybe, if you just stop maintaining and walk away, dependent users will either notice and switch away, or die themselves, and the death will ultimately be quicker and quieter. (1) As an example: https://news.ycombinator.com/item?id=26168596 https://news.ycombinator.com/item?id=26168596

LAC-Tech 4y ago
(1) As an example: https://news.ycombinator.com/item?id=26168596 https://news.ycombinator.com/item?id=26168596 LOL that's an ancient bit of copy pasta. Here's a page from over two decades ago that was already describing it as a "classic troll". https://everything2.com/title/BSD+is+dying https://everything2.com/title/BSD+is+dying
guidedlight 4y ago
Java?
BossingAround 4y ago
Java is live and well, still one of the most popular languages today.
jacquesm 4y ago
MUMPS... arrrrggghhhh.... instant outbreak of skin rash and stress just from hearing the name. Thank you. ;) Seriously though, that was one interesting language, the number of weird features (the editor is a string) that you'll come across in MUMPS make it fascinating just to study and wonder what inputs into the decision making process around the design trade offs were.
4y ago

nigamanth 4y ago

I remember using Python 2, if not for Python 3 it would've never become as big as it is today tbh. Been long enough for everyone to migrate to python3, and this finally happened.

latenightcoding 4y ago
Doubt this. Many of the libraries that made python so popular were born in Python 2. e.g: most ml and scientific computing libraries still used today.

whirlwin 4y ago

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 again, please.

lifthrasiir 4y ago
> 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 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. [1] https://github.com/python/cpython/tree/main/Lib/lib2to3 https://github.com/python/cpython/tree/main/Lib/lib2to3
- kasabali 4y ago
  > first major language with this approach was ECMAScript 2009 (5th ed.) Not that I've any proof but I kind of find it hard to believe there were no other examples before
  - TJSomething 4y ago
    Perl's original "use strict" was added in 1994 with Perl 5, to allow backward compatibility with Perl 4 scripts.
  - masklinn 4y ago
    Python had that long before js, with __future__ imports. But editions & friends are for syntax. Python 3 changed semantics all around. Editions are not an option when you’re changing the langage’s entire text model, especially without static typing.

potamic 4y ago

And as we speak, I upgrade to 3.10 only to see my dependencies break and wonder if they have learnt anything at all.

thomasahle 4y ago
I don't think there are any breaking changes in Python 3.10? Sounds more like a package management issue.
- qwertox 4y ago
  Depending from which version you're upgrading from. I think there are breaking changes between 3.7 (or 3.8?) and 3.10 regarding the asyncio loop. I had (simple) servers cause exceptions because they used `loop` as a keyword argument which got removed without proper deprecation.
- jjluoma 4y ago
  At least they removed something that had been deprecated ERROR: gcloud failed to load: module 'collections' has no attribute 'Mapping'
  - EdwardDiego 4y ago
    That was a 3.8 change I think? It moved from collections to collections.abc, IIRC.
    - Beltalowda 4y ago
      In the 3.9 release notes it says "Aliases to Abstract Base Classes in the collections module, like collections.Mapping alias to collections.abc.Mapping, are kept for one last release for backward compatibility. They will be removed from Python 3.10" but the 3.10 release notes don't really mention it. Apparently it's been emitting a DeprecationWarning since Python 3.3 (2012), but still... I like to have things "just work" even if I return to them after 5 or 10 years.

tgsovlerkhgsel 4y ago

Glad this is finally mostly over, but... that was bad. I wonder if the energy that had to be put into this migration by everyone involved was worth what seems to be relatively small improvements. The print-as-a-statement was ugly but convenient and didn't seem like a big deal, the integer division was something that you could live with once you knew about it (and you still need to know what the current behavior is), and the new string types make code more verbose, and the way they were handled introduced countless hard to find bugs during the migration.

gspetr 4y ago
IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013): https://www.youtube.com/watch?v=f_6vDi7ywuA https://www.youtube.com/watch?v=f_6vDi7ywuA
- p-e-w 4y ago
  > "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then maybe it would have been. As it stands, Python's biggest weaknesses remain unaddressed.
  - EdwardDiego 4y ago
    > The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. That's reading far too much into a tongue in cheek presentation title. Besides, good devs are typically reasonably skeptical of new and shiny. And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment. Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features. And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.

yieldcrv 4y ago

Good riddance

_8j50 4y ago

This really sucks but at least pyenv exists. Basically distros care so little about their users we have to use external tools to use python2. "Everyone has has a chance to migrate" . Doesn't work that way, just yesterday I spent a few hours trying to get scripts that are really good and would take me forever to migrate that are in python2 to work on an ubuntu based distro and this is with pyenv, custom venv,etc... just when you get python syntax worked out you are faced with deprecated or uselessly renamed imports and modules. This is the shitty aspect of using foss stuff. I don't pay for it so I have to accept their decission. But in the broader sense, inability to influence things like this even with a ton of other people willing to pay for it is frustrating. You know what would be great? If the community can vote with money pledges. So it you have 1000 people willing to donate $10/month to support python on sysv init then if volunteers don't want the money we get an external person getting paid 10k/month to support these packages even if the corporate types, developers and "devops"/sysadmin people have no use for it. The free part of foss is expensive but I think the middle ground is to collectively pay for the support. I try very hard to avoid python2, I am not a developer and I very easily lose at least 1h/month on average to resolve these issues. Do you all know why 2023 will not be the year of the Linux desktop? Because desktops are a commercial market and consumers/users cannot sway what the Linux desktop experience is. They either accept things as they are or pay for them by spending time reporting bugs, troubleshooting stuff, asking questions on random sites,etc... a lot of this has to do with change and maintenance requiring human time and resources. It's great when there are no issues and volunteers donate their time but it would be great to be able to pay with money also to support features or resolve issues. You can even make sure multiple people pay an equal amount to avoid wealthy people having too much or an influence but it still will not affect regular volunteer work. I was hoping Ubuntu and Fedora would have such features.

yjftsjthsd-h 4y ago
> Do you all know why 2023 will not be the year of the Linux desktop? Because desktops are a commercial market and consumers/users cannot sway what the Linux desktop experience is. And... you believe that Microsoft and Apple are swayed by users? More than Red Hat and Canonical? I don't buy that for one second.

qwertox 4y ago

I liked how Canonical did it: the command `python` would not execute, you have to use `python3` explicitly. This means that your old Python 2 code would not get executed if it were triggered by some shell script via the `python` command, you'd have to fix the shell script and become aware that you still need to migrate the Python script.

orangepanda 4y ago
I dont know python. Does python3 have different behaviour than python2 on the same code, beyond just crashing?
- mau 4y ago
  You can write code that runs in both interpreters. Same syntax can have different behavior. I guess nowadays, as the py2 compatibility is a thing of the past, most programs would crash when using that interpreter version.
- Tom4hawk 4y ago
  Integer division
bayindirh 4y ago
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.
- ilyt 4y ago
  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

Flimm 4y ago

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!

thrdbndndn 4y ago
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 bytes. I mean, it of course has its upside, but I don't think it's worth it if you care even slightly beyond ASCII.
- mrweasel 4y ago
  We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief. Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017.
  - Jenda_ 4y ago
    > Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017. For example GnuRadio started supporting Python 3 with GnuRadio 3.8 released in 2019, and then you had to port all your programs using it to this version. So no, in 2017, the ecosystem was not ready.
  - 4y ago

psychphysic 4y ago

2to3 really showed that Python didn't understand their audience. If they had started a new project called COBRA and just eventually had it over take python the world would be all over it. But massive breaking changes going from 2 to 3 was a disaster for their audience. Worse still you could hear the acrimony in Pythons communications on the topic.

groestl 4y ago
I'm wondering, is there work on how python 3's changes could have been promoted in smoother way?
- EdwardDiego 4y ago
  An excellent question, how do you smoothly break compatibility?
  - tormeh 4y ago
    Really annoying deprecation notices help a bit.
  - broeng 4y ago
    I think two aspects have played a significant part in the migration pain: 1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable. 2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI. Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
    - peterfirefly 4y ago

pjmlp 4y ago

Meanwhile we are still living our Python 2 like moments in .NET and JVM ecosystems, with the huge amount of projects stuck in .NET Framework and Java 8, with no end in sight of them ever moving forward.

matsemann 4y ago
It's not as big of a deal, though. Code written for java8 is still source backwards compatible on newer platforms. And in .net/jvm you're not depending on some interpreter on the OS level and don't have code bundled with the OS, as has been the big issue with lots of small python scripts included in various distros.
- pjmlp 4y ago
  On .NET Framework you surely depend on OS integration, that is one of the major design changes in .NET Core. Starting with Java 9, finally the long deprecated APIs started to be removed. In any case, the issue is that we are forced to write C# 7 and Java 8 code. Some well known examples, Sitecore, SharePoint WebParts, SQL Server SP extensions, Dynamics, Office AddIns, VS plugins, Solr extensions (many places keep using Solr on Java 8 even if more recent versions exist), Android (unless one goes Kotlin or targets version 12), Forms and WPF 3rd party components (the versions on .NET Core are incompatible due to new designer)...
mnau 4y ago
Yeah, I hoped MS would be more supportive of .NET Standard 2.0 during transition period. I am stuck on .NET48 at least for another two years (because of webforms frontend) and the last version of EF Core that supports .NET Standard 2.0 is 3.1. They dropped .NET Standard 2.0 like a rock... for what? Few default interface implementations. Or nullability attributes that are missing in .NET Fx, they could also be defined externally, like R# does. Nope, sucks to be you.
was_a_dev 4y ago
My previous, and only, software developement job involved migrating a monolithic .NET Framework web app to .NET 5.0 Compared to Python 2->3, the breaking changes were more obvious as they involved entire strucutres and paradigms being deprecated. Python 2->3 felt a lot more subtle despite being just as damaging.

sherr 4y ago

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 support ends. I'd rather not have to have another VM though.

rc00 4y ago
I had a VM with MediaWiki way back when and I was able to convert it to markdown and a private GitHub repository pretty easily with pandoc. I'm not familiar with Moin Moin but maybe there's a conversion tool you can use to do the same thing?
oefrha 4y ago
Just make a container for it and you can run as many of them as you like without VM overhead.
dvdkon 4y ago
MoinMoin2 exists and works on Python 3, but sadly there's still no stable release and it requires slightly older Python packages right now. We've also had strange problems with index (Whoosh library) performance on a large wiki that we had to hack around, but it might be a good migration path for you. And if you don't want to use moin2, it can convert the custom markup to Markdown, which you can then use elsewhere.
solarkraft 4y ago
What shocks me is that MoinMoin doesn't support Python 3.
- Beltalowda 4y ago
  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 https://moinmo.in/MoinMoin2.0 anyway.

andrewstuart 4y ago

It craps me off that I still need to look up which direction to encode/decode strings and other things like bytes and ascii even after programming Python 3 for more than 10 years. It's a huge usability fail on the part of Python that it's not obvious and easily memorable how to do this.

maxbond 4y ago
You encode strings to bytes, you decode bytes to strings. A string is an abstract representation of text, which can be encoded into whatever supported format you'd like; bytes are a concrete representation of binary data, such as text encoded in UTF8, which, if it represents text, can be decoded to obtain a string. If you think about it, that's the only way that makes sense; if you wanted to go from, say, UTF8 to UTF16, you'd need to have an intermediate step that was abstract and formatless. Similarly, when you're operating on text, you don't want it to have a particular format; the format should only exist at the edges, where you take text in and output it. The format is a way to communicate with other programs, not components within your program. My advice would be, if that doesn't stick in your head (totally legitimate), write down a code example and stick it in a personal wiki or something. I find it really helps me to understand something once and more or less copy paste it forever.
- andrewstuart 4y ago
  I understand the reasons, it’s Python's fault that it’s not easy to remember and program. This is a key reason why people hated Python 3 so much IMO. For context I’m a huge advocate of Python 3, except for this (and lambda functions, but that’s another whine session).
saila 4y ago
It's not that complicated nor is it a Python specific issue. This is a good article on the topic: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ https://www.joelonsoftware.com/2003/10/08/the-absolute-minim... A simplistic summary is that you always decode to unicode and always encode to bytes. Another way to think about it is that Unicode is an idealized character model that is reified into a byte encoding, usually UTF-8, for practical usage. It seems to me that this is something a lot of developers don't think too much about until they run into some obscure encoding/decoding issue, but it's kind of a fundamental aspect of programming that's worth spending some time grokking.

bad-engineers 4y ago

KILL IT WITH FIRE

mikewarot 4y ago
Yes, Kill PYTHON3 with Fire, end this stupid unicode fetish!

w4rh4wk5 4y ago

Congratulations! Guess we finally managed to move on :)

bb88 4y ago

Good.

willis936 4y ago

Reminder that python 2 was liked once. https://xkcd.com/353/ https://xkcd.com/353/

mikewarot 4y ago

I can't use Linux as a daily driver because of the Python 2/3 breaking change. My personal wiki (WikidPad) just doesn't work properly under linux due to the changes that happened in Python and then wxWindows. There are ports that barely work, but all the dialog boxes to adjust anything just error out. It's really sad that the Python folks committed suicide this way, all over a unicode fetish.

nmstoker 4y ago

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.

rpep 4y ago
I worked on a code base which had a large dependency not port to Python 3 until 2018, and at the same time they made a huge ton of changes to the APIs, most of which were not documented well. So there was both a big refactoring to handle binary data transfer between it and the application, and also a ton of other unrelated things just to make it work. It's things like that that made it difficult to port for most people.
hnfong 4y ago
The lack of type checking and general runtime failures made the transition particularly difficult if you didn't have a bazillion unit tests covering all your large codebases. I was lucky it didn't affect me much, but I could sympathize if somebody had hundreds of thousands of lines of python2 legacy code that needs to be migrated..

thiht 4y ago

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.

pjc50 4y ago
> Are there some valid reasons that made 2->3 migration insanely hard for some projects? Print was a non-issue once you could do "from __future__ import print_function". It was the unicode migration. All string handling from I/O required at least checking. The dependency issue was the most crippling, though: because you can't load Python 2 code from Python 3, before your project can begin migrating you have to wait for all your dependencies to update as well. This may involve them changing the types that get passed over the API from 'str' to 'bytes' or vice versa, which is potentially a breaking change.
- nonethewiser 4y ago
  Sounds like a circular problem
MereInterest 4y ago
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 case applies. For python2, the str class could either contain a sequence of characters, or could contain a sequence of bytes. These are often conflated when using ASCII encoded text, but are very different for any other encoding. In python3, these are represented by the str class for a sequence of characters, and by the bytes class for a sequence of bytes. It’s so much nicer to work with, but required manually separating out the earlier use case.

sovietmudkipz 4y ago

When (if?) the dust settles, I'd love to watch a technology focused documentary to hear the historic retelling of all the python 2 to 3 events. It started before I started programming, I don't program in python much, and thus I don't have a ton of context. If anyone has any good resources I could browse that might help me understand the full story feel free to share.

pnt12 4y ago
My 2 cents: I learned python 2 in 2015 or so because I was recommended "Learn python the hard way", whose author defended python2 with a passion. So I started with python 2 and found the book crap. The author's idea of teaching is telling others to repeat an exercise a hundred times with all possible variations. There were more than a dozen about printing stuff to a terminal, before you got into any interesting stuff. From their website, although they added a new course and book for python 3, they are still selling the ones for python 2. Still selling stuff for a version killed 3 years ago requires some fucking audacity. Later I learned python 3 from other source and loved it. It's what I mostly program with today.

tolmasky 4y ago

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.

Apofis 4y ago
I just avoid Python and any job descriptions that contain it. It's never been a good experience for me, whether as an end user or a developer. It's nice that they may have ironed out their issues, but I've been done a long time ago. There's nothing Python does I can't do better with some other toolchain.
Waterluvian 4y ago
I’m curious why installing Python 3 causes Python 2 programs to break. The only reason I can come up with is that the installation process is wrongly changing the `Python` symlink. Anyone have other known causes? Does it screw with dependencies?

nano9 4y ago

I welcome Python3 just fine. Character data no longer being automatically ASCII might be a bit annoying, but it's fine if that's what it takes to support a more global developer base. I just wish they would stop iterating on the minor version so quickly. Why are we on python 3.11 (for workgroups, just kidding)? Is there that much of a difference compared to 3.7? 3.7 even has dicts with stable key insertion order and type hinting, so it seems pretty loaded if you ask me.

pistolpeteDK 4y ago
I don't think we'll see a version 4 for the next decade or so (because of the python3 debacle) - so it'll probably just be various improvements to the standard library. There's a lot of improvements being made to Python on these minor versions. So while the version bump looks minor, they can make quite a big impact. 3.11 improved performance by 25-60% (depending on use-case). 3.12 is set to improve performance yet again (Special thanks to Mark Shannon, GvR and Microsoft). On top of that there's a lot of quality-of-life improvements for the various parts of the std.lib. I like this apporach very much, since upgrading to a new minor Python version is somewhat trivial
- Izkata 4y ago
  Performance improvements without changes to the interface seems like it should have been 3.11.1; were there other changes?
mort96 4y ago
Were strings in Python 2 really only ASCII? I was sure you could put UTF-8 data in Python 2 strings?

at_a_remove 4y ago

I'm in an extremely weird, one-off position (a chain of interesting dependencies) where I am still on Python 2.7. Not sure when we'll be able to move to a newer version but it sounds like a lot of the growing pains have been dealt with. It should be interesting, most of my inputs are still in ASCII-land. (I know someone who will pretend to know my situation better than I will advocate for some "solution;" no, it won't work in a way that won't break some of my priors)

hartator 4y ago

print "sad"