6 ms·
> Python only just barely survived the jump from 2 to 3. I really don't think this is true at all. Python 2 to 3 took a really long time, it was a real strugg
by kaashif 11mo ago
> Python only just barely survived the jump from 2 to 3.
I really don't think this is true at all.
Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.
But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.
There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.
There was never anything similar for Perl 5 to 6, totally different situation.
- zahlman 11mo ago> There was always a clear way forward and people were actually moving. I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.
- masklinn 11mo ago> the movement not nearly as difficult as people claimed. Original was really rough because the core team had gone in the wrong direction on migration, and the Python io module was hell as well. By 3.3-3.4 it was relatively smooth sailing but that took a lot of work from the community and core team both (reminder that Python 2.7 was released after 3.1, backporting a number of features to make compatibility easier, and old features were reintroduced as late as 3.5).
- zahlman 11mo agoI started on 3.2 and found it reasonably smooth (dealing with encodings in 2.x was also not pleasant IMX if you also cared about universal newline support at the same time), but I will definitely cede that 3.0 and 3.1 were Not Ready.
- foobarian 11mo agoCan you imagine if the PSF had been working on Python 4 in parallel, with more backwards compat shifts or even a radically modified syntax? I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".
- foofoo12 11mo ago> I really don't think Python was close to dying It absolutely was. What saved it was: 1. The data science / AI crowd that was gathering momentum any many only used Python 3. 2. No popular alternative. Perl got python as an alternative. Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
- mixmastamyk 11mo agoI was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first. None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.
- selcuka 11mo agoPorting your own code was relatively easy. The problem was porting all your dependencies, and replacing the ones that were abandoned and didn't support 3.x.
- mixmastamyk 11mo agoI did wait a bit for Django and SQLAlchemy but it wasn't long, they may have been ready for 3.6. Small deps were replaced or eliminated.
- masklinn 11mo agoThey were ready long before 3.6, sqlalchemy added support for Python 3.1 in 0.6, and Django 1.5 introduced support for Python 3.2 on an experimental basis with 1.6 removing the “experimental” bit.
- dist-epoch 11mo agoYou're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?
- dist-epoch 11mo agoPython continued growing fast during the 2 to 3 transition, it was nowhere near dying. It was one reason it took so long, people were starting new Python 2 projects 5 years after Python 3 was released. Only around 2017/2018 the default for new projects kind of became Python 3.
- orev 11mo agoPython 2 was used for such a long time because many modules only worked on 2, which was a direct result of the compatibility being broken. There was a catch-22 for a long time that nobody would upgrade to 3 because nobody else would.
- raverbashing 11mo agoI agree If anything might have killed python it was not python 3 per se but shipping a "beta" version of Py3 as 3.0 Python 3 only got usable really around 3.3 or maybe 3.4
- Izkata 11mo agoNot sure why this was downvoted, 3.3 was when they started re-adding things that were removed in 3.0, to make supporting both 2 and 3 reasonable for libraries. I think it kept going in both 3.4 and 3.5 with more features, but the 3.3 restoration of the "u" string prefix is the one that I remember.
- sleepybrett 11mo agoThe delta between python 2 and 3 was much smaller than the delta between perl 5 and 6. Perl 6 might as well be a totally different langue which is probably why they renamed it to Raku, to stop people thinking that it was the same language.
- kvemkon 11mo ago> Python 2 to 3 took a really long time It took AdaCore so long to port the plugin system of the GNAT Studio (GPS) to Python 3 (which seems to be a fraction of the whole code base), that even conservative Debian had to remove the whole GNAT-GPS package. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082332 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082332
- true2octave 11mo agoI know companies with a big Python 2 stack that rather preferred to rewrite in typescript than migrate to Python 3 I turned down one of those companies because I didn’t want to deal with that migration in 2021
- LexiMax 11mo agoI will never forget Mercurial's postmortem on their experience with the Python 3 transition. They had very few kind words to say about the process. https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey-to-and-reflections-on-python-3/ https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey... Part of me even wonders if the transition had any role to play in why Mercurial gradually lost whatever foothold it had in the DVCS ecosystem.
- tacker2000 11mo agoVery interesting article. I too was rather upset about the Python 2->3 shenanigans and I was working on much smaller projects.
- nyrikki 11mo agoFor the crowd I ran in the lack of real branching and the need to use DirState or Queues for selective commits made Mercurial feel too much like p4, where git felt so freeing, especially with spikes etc...which would be forever in the repo with Mercurial etc... > This ground rule meant that a mass insertion of b'' prefixes everywhere was not desirable, as that would require developers to think about whether a type was a bytes or str, a distinction they didn't have to worry about on Python 2 because we practically never used the Unicode-based string type in Mercurial. > In addition, there were some other practical issues with doing a bulk b'' prefix insertion. One was that the added b characters would cause a lot of lines to grow beyond our length limits and we'd have to reformat code. I wonder if their line length was arbitrarily 80chars or some silly serial terminal like limit. > It is now 2020 and Python 2 support is now officially dead from the perspective of the Python language maintainers. Linux distributions are starting to rip out Python 2. Packages are dropping Python 2 support in new versions. The world is moving to Python 3 only. But Mercurial still officially supports Python 2 To me it doesn't matter what pain points there were between 2/3, or that it was even python. That is just the classic way any modernization effort fails. IMHO those failures are almost completely tool agnostic and are cultural failures.
- notepad0x90 11mo agoIf Golang was around, it might have killed python then I think. To many, the 2->3 jump made little sense. I honestly wish they just started a new language instead. I still to this day stumble upon code I have to use 2.7 on, thankfully things like pipx make it easy these days. but still,switching back and forth could be a pain. But you're right, it wasn't like Perl 6. People moved to python and php mostly from perl. what were going to move to from python 2? Ruby?
- loeg 11mo ago> I still to this day stumble upon code I have to use 2.7 on There's always Tauthon (Python 2.8), lol.
- jcranmer 11mo agoPython 2.7 was EOL'd at the start of 2020, and serious effort to move from 2 to 3 didn't start until around 2018, by which time Go was a very major player.
- CamouflagedKiwi 11mo agoMajor-ish. It was getting experimental module support around 2018; arguably go get was already better than Python's mess, but it wasn't great. It wasn't that widespread in industry yet - we could very rarely hire anyone with a Go background at that point.
- loeg 11mo agoPretty major. I started using Go in like 2009 or 2010 and industry adoption was already pretty wide in the mid 2010s (largely replacing Java moreso than Python, IMO).
- notepad0x90 11mo agoI meant when 3.0 was released. By the time 2.7 was EOL'd 3.0 had gained enough momentum to be a viable alternative. It was easier to just migrate to 3.0. In 2018, I don't know if Go was a major player, both it and rust were still new-ish languages. There was still a concern of being able to hire devs if you used them, where as not so much in the past 4-5 years.
- mbreese 11mo agoYou could really make a business case study (well, a project management case study) out of the Python 2 -> 3 transition. It was a very well executed plan. It started with a clear definition of where they were headed (v3) with some good reasons for the technically minded. But the transition itself was really... really... slow. It was methodical and deliberate, but slow. But I think it really happened because developers wanted to move to 3. There was enough momentum and upside for moving to 3 that the Python core developers could keep the migration on track without having to drag people along from 2 -> 3 before they were ready. Making sure that the transition was optional for a long time helped tremendously. I was quite happy working in Python 2 for a long time and only transitioned over to 3 for new projects or code that I thought would have a long lifetime. This was very much a reason why I moved to 3 instead of to another language. At the same time, I'm not sure what language I would have switched to for the things I was using Python for... Perl was out as it had it's own disastrous migration. Ruby was an option, but never really hit the general-purpose scripting language mark for me.
- will4274 11mo ago> It was a very well executed plan. Uh.. You've started in the middle. Python 3.0, 3.1, and 3.2 were insufficiently compatible to support a migration. If not for the effort to reduce 2 to 3 incompatibility by shipping 2.7 and 3.3, 3 could really have failed. I'd say the initial plan was not so good but then the _replan_ after the first setbacks was good.
- mbreese 11mo agoI never saw the initial versions as viable versions for production work. IIRC, neither did the authors. Part of what I think was so good about the plan was that it was a parallel track for so long. They didn’t start the process of sunsetting v2 until v3 was ready to take on the migration. The specific steps taken, versions released, that wasn’t what was so good IMO. It was the time scale. This was a good decade long transition. The fact that Python thought it would have that much time to make the transition was audacious, but it was going to take that long. And now we have a better language that has supported many more years of growth.
- 11mo ago
- snthpy 11mo agoI watched both of these at the time. FWIR Python took some learnings from the Perl experience and it was still close.