22 ms·
Python 2.7.18, the last release of Python 2
- MattGaiser 6y agoStill know a heck of a lot of people using it. Even know one researcher using it for a new project. It will be decades before the final Python 2 program goes offline.
- deleted 6y ago[deleted]
- smitty1e 6y ago"So?" said COBOL.
- mullen 6y ago"Hold my beer!" - COBOL
- Izkata 6y agoJust discovered a week or two ago a pretty important part of one of our internal systems is running on python 2.6
- loeg 6y agoCaveat about 2.7: HTTPS switches from default-non-validating to default-validating. If your internal system uses SSL, and you have a bunch of self-signed certs, for example.
- Izkata 6y agoI think we're prooobably good there, this system is primarily slinging around and transforming data between databases. The far bigger worry would be unexpected encoding issues corrupting the data when going from 2->3.
- downerending 6y agoThere's a lot of code out there that's important, but not worth porting to a new language (which Python 3 is).
- acdha 6y agoI think describing it as porting to a new language is misleading: on most of my projects, most of the work is a few minutes — run modernize/futurize, check the tests, etc. If the original developers were really sloppy about how they handle encoding, it can take longer but most of the problems I've seen have very little to do with Python rather than the fact that something still running Python 2 likely has significant technical debt issues — especially things like not having test coverage which make it a lot harder to ship changes.
- downerending 6y ago> likely has significant technical debt issues You're not wrong, but as a practical matter, that pretty much describes our entire industry.
- acdha 6y agoCompletely agreed — I would just argue that the “Python 2 vs. 3” argument is a distraction. Java hasn't had as breaking a change but there are still a ton of places running Java 6 or 7 because they like skimping on developers more than getting security updates.
- Joeboy 6y agoOur product took about a year to port, from getting the go-ahead to the eventual production switch. Running modernize / futurize was like 0.01% of the work. You're right though, we're fighting our way out of technical debt and switching to python 3 was absolutely necessary. It's forced us to sort out a lot of sketchy string / bytes handling. We do, mercifully, have ~90% test coverage.
- abiogenesis 6y ago
- zitterbewegung 6y agoThere isn’t anything inherently wrong with still using 2.7.x . Just don’t expect updates. For new code using 3.7 is probably the best bet at this time.
- deleted 6y ago[deleted]
- azinman2 6y agoI thought there won't be any more security updates?
- NikolaeVarius 6y agoSo? Im sure my non internet facing scripts care
- acdha 6y agoRed Hat, Ubuntu, etc. are going to support Python 2 for the duration of the operating system releases which shipped it. I would assume that Anaconda, et al. will have similar options for paid customers.
- DCKing 6y agoRed Hat has committed to keeping Python 2 on life support until 2024 as part of Red Hat Enterprise Linux 8 [1] so you can get security fixes for Python 2 until then if you use CentOS 8. Canonical will not provide long term support for Python 2 as part of Ubuntu 20.04 LTS. In Ubuntu 20.04, Python 2 is a "universe" package [2] that does not receive updates by Canonical. This means that the you will only get Python 2 security update guarantees with Ubuntu is on 18.04 LTS until April 2023. Debian is making an active effort [3] to remove Python 2 and packages that depend on it for its next release. It'll likely support Python 2 as part of Debian Buster until 2024. Note that if you're reading this to delay your move to Python 3 by another few years, you're doing it wrong. This list shows even all slow enterprise-y distros have a deadline for Python 2, not that you can stretch your stuff for a couple of more years :) [1]: https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511 [2]: https://packages.ubuntu.com/focal/python2 https://packages.ubuntu.com/focal/python2 [3]: https://wiki.debian.org/Python/2Removal https://wiki.debian.org/Python/2Removal
- deleted 6y ago[deleted]
- colanderman 6y agoYa, there's no way this is the "final" release. Maybe by the core Python team, but it will be forked to fix bugs. Ten years from now there will still be Python 2 code running critical infrastructure at various companies, and the most responsible path to address discovered issues in the runtime will not be "rewrite the application to work in Python 3!" but "upgrade the interpreter to this community-vetted fork of 2.7.18". Mumble mumble something about conflating languages with implementations.
- tom_mellior 6y ago> Mumble mumble something about conflating languages with implementations. So your claim is that "Python 2" is a language spec, not an implementation? And that there will be future releases of this language spec in the future? I doubt it. I agree it's likely that there will be people wasting their time maintaining an interpreter fork, but that will not be Python-the-language (a trademarked term BTW), it will be a fork of the implementation.
- colanderman 6y agoNo, my claim is that, while ceasing development of the language Python 2 is wholly sensible, ceasing development of the implementation Python 2 (CPython specifically) is not (due the almost certain existence of latent bugs). My "mumble" at the end was meant exactly in reference to that. I suppose one could argue that, the CPython implementation is the language specification. (And I seem to recall hearing that notion somewhere years ago.) In which case, it would not be possible to freeze development of the language without freezing the implementation as well. There are various reasons I wholeheartedly disagree with such a characterization, but I guess there's some self-consistency there at least.
- nxpnsv 6y agoThis is clear, but does the cpython team want to maintain Python2? If not, either it’s time to use an alternative or move on....
- tom_mellior 6y ago
- contravariant 6y agoDoes anyone know what the main reason is for not updating from python 2? I'm genuinely curious as I don't really know any modules that won't work under Python 3 and I can't really come up with any other blocking changes that would make upgrading that hard.
- TylerE 6y agoBecause giant codebase that would take effort++++ to do so for no perceived gain, with possible addition of new bugs.
- mywittyname 6y ago> effort++++ effort += 1 + 1 Ported to Python3 for you.
- imtringued 6y agoThat's how we get decades old cobol codebases that nobody understands.
- jefft255 6y agoLot’s of code is simply unmaintained. The guy that wrote it is gone, it’s still running fine so nobody is touching it. Businesses don’t want to take the risk and spend the money to upgrade it. Maybe you don’t realize the insane amount of code that is in this state!!
- BeetleB 6y ago> Even know one researcher using it for a new project. Knowing researchers (at least in academia), they're the last people I would expect to change.
- takeda 6y agoAnd those are least worrying, once they publish their thesis, they don't give a damn about their code anymore and it just dies natural death ;)
- yjftsjthsd-h 6y agoI thought the last release was already past; wasn't the python 2 series supposed to have ended on January 1st? Or did I misunderstand that?
- shpx 6y agoThey stopped making changes on January 1st 2020 https://github.com/python/cpython/commits/2.7 https://github.com/python/cpython/commits/2.7 This is the release of the changes up to that date, since they don't release instantly.
- tecleandor 6y agoFinal fixes from 2019 that got stuck... https://adtmag.com/articles/2020/01/09/python-2-end-of-life.aspx https://adtmag.com/articles/2020/01/09/python-2-end-of-life....
- UnlockedSecrets 6y agoPython 2 ended support on January 1'st however critical bugs reported before then continued to be worked on until this last release. All Python foundation development has now concluded and any further bug fixes will have to either come from the community or another entity.
- nomel 6y ago2.7.18 was the planned final production release [1]: > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to Python 2, and Python 2 is no longer supported. We have not yet released the few changes made between when we released Python 2.7.17 (on October 19th, 2019) and January 1st. As a service to the community, we will bundle those fixes (and only those fixes) and release a 2.7.18. We plan on doing that in April 2020 [1] Sunsetting Python 2: https://www.python.org/doc/sunset-python-2/ https://www.python.org/doc/sunset-python-2/ [2] When is the last release of Python 2.7 coming out?: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#when-is-the-last-release-of-python-2-7-coming-out http://python-notes.curiousefficiency.org/en/latest/python3/...
- deleted 6y ago[deleted]
- amenod 6y agoI still occasionally mistype `print s`. RIP, python2, you will be missed. And a big thank you to all the contributers who have kept it alive for so long!
- Andrew_nenakhov 6y agoI still feel very wrong whenever I have to use print(), it was so much better without ()
- ghshephard 6y agoHas anyone seen a recent survey of which version of python developers are starting projects with?
- Scarblac 6y agoI haven't heard of anyone starting a new project in 2 in several years.
- judge2020 6y agoSee: https://www.jetbrains.com/lp/devecosystem-2019/python/ https://www.jetbrains.com/lp/devecosystem-2019/python/
- loeg 6y agoIt's probably worth considering the number of former Python developers who were bit by this or other breaking changes in 3.x and have moved on from the language entirely.
- pensatoio 6y agoI start every project on the latest widely compatible release. atm, that's 3.7 or 3.8. Once you're using containers, shared build tooling, and enforcing linting/testing, the version you use doesn't matter as much, imo. Unless you're using an advanced feature that's still developing (rare..only seen it a few times), most projects can upgrade minor version with zero codebase changes. Just lock a new environment, format code, and push to CI.
- jimbob45 6y agoIs this the most infamous failure of a version upgrade ever in software history?
- fzzzy 6y agoPerl 6?
- loeg 6y agoPeople actually use Python 3, though. The Python developers succeeding in forking the language and community. No one really uses Perl 6, as far as I know. You're right that Perl6 is another great example of a bad language fork decision.
- fzzzy 6y agoI feel like the Python 3 experience could have been predicted by looking at the Perl 6 experience.
- lizmat 6y agoIt's not too late to change the name of Python 3, just as Perl 6 has changed its name to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). :-)
- RMPR 6y agoThe community is certainly not that much into Raku, but from this past thread https://news.ycombinator.com/item?id=22906703 https://news.ycombinator.com/item?id=22906703 > On the #raku channel on Freenode, several users are using Raku in production.
- lizmat 6y agoSome vocal members of the Perl community have not been into Perl 6. That didn't change with the name change. But if anything, the change in name should make clear that even though Raku is clearly a programming language in the Perl lineage, it is not aiming specifically for the Perl community. Anymore, at least.
- csande17 6y agoIf you're interested in what actually changed in this update, the release notes are here: https://github.com/python/cpython/blob/2.7/Misc/NEWS.d/2.7.18rc1.rst https://github.com/python/cpython/blob/2.7/Misc/NEWS.d/2.7.1...
- memco 6y agoTrying to click the release notes for it on https://www.python.org/downloads/ https://www.python.org/downloads/ seems to do nothing. I'm working on legacy apps running on 2.7 so I'm eager to see what's included.
- wichert 6y agoAs far as I can see this should be the list of changes: https://github.com/python/cpython/blob/v2.7.18/Misc/NEWS.d/2.7.18rc1.rst https://github.com/python/cpython/blob/v2.7.18/Misc/NEWS.d/2...
- talentedcoin 6y agoFinally. Please let it die.
- shadowgovt 6y agoLanguages that receive wide adoption never die. Anyone who thinks they do should go sign up for some COBOL training so they can grab those sweet New Jersey contracts. ;)
- talentedcoin 6y agoI'm sorry, but characterizing Python 2 as a completely different language than Python 3 just makes me laugh. Is American English a completely different language than British English? (I realize this isn't the best comparison, just trying to make a point.) Like I said, I acknowledge there were costs to transitioning. Python 3 was pretty rough around the edges upon first release. But that first release was in 2008 ... I realize not everyone needs to upgrade, and that's totally fine. But how people internally justify the cost of keeping Python 2 going when the momentum and most of the community is with Python 3 I cannot understand. Unless you're in a very inflexible corporate setting ...
- readmodifywrite 6y agoIt is a completely different language - it is syntax incompatible. Human languages are a very poor comparison to computer languages. It's just a tough sell to manually update a huge pile of code that works just fine as-is. No new features will be introduced. No bugs fixed, while some new ones may pop up. There's a lot of manual work in porting, the automated tools only cover the basics. Your downstream customers receive very little benefit for this effort, which makes it very hard to justify spending the engineering resources on it.
- talentedcoin 6y agoI appreciate what you folks are saying, but from my perspective this is exactly what I mean by the absence of a "good technical reason". I also appreciate that there are a small number of projects (e.g. PyPy) that probably do require some of the special sauce around CPython 2. But for everyone else ... come on folks. We're developers and engineers, we're supposed to be the creative builders of tomorrow and all that stuff. Is this really so hard?
- tedunangst 6y agoAnd now for python 2.8. From somewhere, if not python.org.
- loeg 6y agohttps://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon is one candidate. PSF controls the Python trademark, so forks can't actually call themselves Python 2.8.
- tialaramex 6y agoCaring for dwindling groups of increasingly eccentric users sucks. That doesn't mean nobody will do it, especially at first, and especially if there's money in it, but don't expect such maintenance efforts to have much staying power.
- jhayward 6y agoI don't expect that because the Python 2 die-hards are, shall we say, not a maintainer-friendly crowd. You'd have to pay me FAANG bucks to even consider it.
- linsomniac 6y agoWe've switched off Python 2, but I really miss it. For a glorious several years we were done with "production has Python X.Y, but the code needs X.Z" and always chasing the latest minor version on LTS OS releases. But now we're back on that treadmill...
- brianwawok 6y agoHow long does python upgrading take you? I think Python 3.7 to 3.8 was change my docker version and push to CI... 5 minutes later it told me all tests passed and I deployed to production??
- Scarblac 6y agoBut what version does production have, and all the other servers and projects?
- kevinmgranger 6y agoThat wouldn't matter if you're using docker, unless I'm missing something here.
- brianwawok 6y agoExactly. Each of my apps has their own python runtime. Running on top of kubernetes. Man in 2020 if you are SSHing between boxes and upgrading python by hand, you really should invest in some devops. Even 5 hours a week.....
- aprdm 6y agoI hope you realize not everyone running python is running web apps. There are huge companies that use python for automation and they all run from some computer grid storage (usually NFS) and are imported in the same environment as the client instead of having a server side environment separated from the client side environment.
- loeg 6y agoPerhaps, but only because the PSF wields the Python trademark to prevent people who want to continue releasing the Python 2 language from doing so: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
- rowanG077 6y agoGood! I would hate to have 300 different flavors of Python with no clear way to know which is which.
- MiroF 6y agoRightfully so - it would be incredibly confusing to have a third-party python with the same name but maintained by a different group of people. There's no "right" to the python name. If you actually look at the issue discussing this, you can see that Guido is being more than amenable and the responses are honestly verging on childish.
- talentedcoin 6y agoWell put. That's been my feeling about all of this in a nutshell. Guido was a saint for putting up with all this as long as he did. Some people really need to get a grip.
- loeg 6y agoSure, I agree generally (which is part of why forking the language under the same name was a poor choice!). However, python.org has demonstrably zero interest in the Python 2 language and CPython runtime. So they can both say "see, there's no interest in community maintained Python 2" and also prevent that community from organizing itself under the name everyone uses at the same time. IMO, Python 2 is a genericized trademark like Kleenex at this point.
- duckerude 6y agoIs the name really an obstacle to organization? And have the Python maintainers ever claimed that there's no interest in a community-maintained Python 2?
- The_Colonel 6y agoI'm curious if there's going to be some community supported fork. Software using Python 2.7 won't magically disappear and I believe there is going to be a demand after fixes. (I know about Tauthon but I don't think it applies here ...)
- badsectoracula 6y agoThere is Tauthon[0] that (they said) also backported several features in non-backwards compatibility breaking ways, but the last commit to the repo was from December. Perhaps after running it for 3-4 years (and faced hostility from some Python devs - i remember at some point being downvoted just for mentioning it on Reddit), the maintainer got tired of it? [0] https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
- guitarbill 6y agomight also be indicative of how many people yelling for a fork were actually willing to put in the time to maintain it or pay for it? (most places i've worked at, when we do the calculations for the business it's much cheaper/less risky just to upgrade to python 3, rather than to support python 2 or switch languages)
- talentedcoin 6y agoThat would be great imo. Then the rest of us who are happy with Python 3 can just get on with life. I'm willing to bet that the demand is not really there and most of this is just kvetching. Should have happened a long time ago. I'm not aware of any good technical reason to still be using Python 2. There is the "I don't have time to upgrade" argument, and I recognize the cost is real. But now we'll see at last if people are willing to stick up for Python 2 more than just figuratively.
- dagmx 6y agoDependencies in computer graphics is still a big holdout unfortunately. The industry is still not in the process of porting major pieces of the ecosystem. It’ll be another 3-5 years i estimate
- phendrenad2 6y agoI expect many forks.
- mrweasel 6y agoBut none that are actually going to be maintained in any meaningful way. Maintaining Python 2 is a huge job, which is also why the Python core team can't do both 2 and 3 at the same time.
- badsectoracula 6y agoWell, the team that maintains the fork wont need to do both 2 and 3 at the same time either, just 2 :-P.
- sigzero 6y agoNo but they will have to sell the "it's not official Python 2" line.
- phendrenad2 6y agoI didn't realize how much effort it would be. Indeed, I think that comports with what I've seen from other forks - it takes a huge effort to keep it going.
- mark-r 6y agoYou mean pitchforks?
- xscott 6y agoFor those with Python 2 baselines that aren't (or will never be) ported, PyPy will support version 2 basically forever [0]. PyPy supports a huge number (but not all) of Python packages, including numpy [1]. Moreover, PyPy is significantly faster in many cases [2], and for the numerical types of things I like to write [3], it's amazingly faster. > time pypy mandel.py > pypy.pgm seconds: 0.318101 real 0m0.426s user 0m0.396s sys 0m0.013s > time python2 mandel.py > python2.pgm seconds: 30.141954 real 0m30.156s user 0m30.136s sys 0m0.003s That's just a silly Mandelbrot example, but for numerical algorithms like this PyPy is nearly 100 times faster than Python2, and that includes startup cost for the JIT! I'm not in any way associated with the PyPy project, but I can't help but believe a sane world would've moved from Python to PyPy in the same way everything moved from Brandon Eich's original JavaScript interpreter to the modern JIT ones like V8. [0] https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s... [1] http://packages.pypy.org/ http://packages.pypy.org/ [2] https://speed.pypy.org/ https://speed.pypy.org/ [3] https://godbolt.org/z/J9Xwp6 https://godbolt.org/z/J9Xwp6
- dilap 6y agoAnother casualty of python 3?
- xscott 6y agoHonestly, I think Python's C API exposing so much of the internals of the implementation is the real problem. You can basically see every pointer in every struct, including tons of things you shouldn't need. Large packages inevitably end up using some unfortunate detail which couples them tightly to CPython, and this makes using those packages with PyPy nearly impossible. The fact that PyPy got so many of those to work as well as they did (numpy stands out) is a testament to their talent and stamina. I believe this is also a huge part of the reason why migrating from CPython version 2 to version 3 was delayed. I've adapted a few small C extension modules to run under both, and using #ifdef for the special cases to support both was unpleasant. So I imagine that any large package which needed to support both through the transition really suffered for it.
- wiremine 6y agoThis isn't a knock per Perl, but looking back, it's really interesting to see how the two communities handled their respective transitions: Python 2 to Python 3, and Perl 5 to Perl 6 (now called raku [1]) I say it isn't a knock because I think they were equally fine with the goals: Perl was looking to make a bold break towards an unknown future [2], and Python wanted a very slow and sustainable migration. I'm glad to see Python 3 go mainstream, I'm glad that Python 2 succeeded so well, and I'm glad there are segments of computer science that still throw mugs and aim for the moon. [1] http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-renaming-perl-6-to-raku.html http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-... [2] https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.html https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.h...
- donio 6y agoYou have it backwards. Perl 6/Raku is a completely new language, the mistake there was to call it "Perl". Perl5 on the other hand has handled its evolution much more gently than Python 2 -> 3 did.
- CydeWeys 6y agoRaku isn't a completely new language. It's very clearly a descendant of the Perl lineage.
- INTPenis 6y agoYeah but I think they have a point. As a former Perl user and current Python convert I do think the mistake was to call Perl 6 Perl. It gave me at least a false sense of thinking Perl 5 was done and going to be replaced. At the same time I found Python to be much easier to write, maintain and I became attached to the structure that PEP provided. There were a lot of other factors that made me switch, but that particular point of not calling Perl 6 Perl made me think.
- arunix 6y agoThere's more to it than that. Looking at its early history [1], it is clear that Perl6 was conceived/intended to be the next version of Perl after Perl5 e.g. First, Perl will support multiple syntaxes that map onto a single semantic model. Second, that single semantic model will in turn map to multiple platforms. Multiple syntaxes sound like an evil thing, but they're really necessary for the evolution of the language. To some extent we already have a multi-syntax model in Perl 5; every time you use a pragma or module, you are warping the language you're using. As long as it's clear from the declarations at the top of the module which version of the language you're using, this causes little problem. There were even plans for a translator [2] similar to Python's 2to3 tool Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax. In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5. [1] https://raku.org/archive/doc/design/apo/A01.html https://raku.org/archive/doc/design/apo/A01.html [2] https://raku.org/archive/faq.html https://raku.org/archive/faq.html
- Qub3d 6y agoMy personal thoughts on the matter aside, here is an informative post from Brett Cannon on why the Python 2/3 split happened: https://snarky.ca/why-python-3-exists/ https://snarky.ca/why-python-3-exists/
- loeg 6y agoThat's what happened to fork the language, but really glosses on the "why." Paraphrased: "People were too lazy about using the unicode type and bytes type, so we forced all string constants to be unicode." I think there is some cognitive dissonance between thinking this fixes lazy programmers and expecting codebases to be rewritten in the new language. (I.e., by who? Those same programmers too lazy to use the unicode type?) Also, all the world wasn't unicode at the time and still isn't (unfortunately, IMO, but still the case). We still have customers using various non-Unicode encodings and not all characters have a 1:1 encoding/decoding round-trip through Unicode.
- pseudalopex 6y agoThe article does say people get lazy or performance hungry but the theme of that section is people making mistakes. The part about Unicode is about how much Python 2 code accidentally only handled ASCII. Python 2 requires handling other encodings as bytes anyway.
- takeda 6y ago> That's what happened to fork the language, but really glosses on the "why." Paraphrased: "People were too lazy about using the unicode type and bytes type, so we forced all string constants to be unicode." I strongly disagree. I actually tried using unicode correctly in python 2, it is actually quite hard. It's similar to using memory safely in C, it is possible, but there are many gotchas. In python 3 all of this is done with no effort.
- hypewatch 6y agoPython 2 had a great run but python 3 is more than ready for prime time. It was pretty bad for a while but since 3.6 it’s been awesome!
- takeda 6y agoAgree, actually it started being usable since 3.3 (and each following version was better than last one), but 3.6 was when there was no longer anything that python 2 was better at.
- deleted 6y ago[deleted]
- gonational 6y agoI love so much about Python 3. Python 2 has paid the bills for over a decade, but I love writing Python 3.8 so much more. I even love the walrus operator. We’re in the process of upgrading, finally.
- at_a_remove 6y agoI am still on Python 2 due to complex vendor reasons. Probably will be for a couple more years. I wish folks were a little more understanding that edge business cases exist that they might not have considered; it isn't all greenfield development.
- mixmastamyk 6y agoFree support for ten years! Doesn't get any better than that.
- at_a_remove 6y agoWish I could get pip running. That'd be nice.
- otabdeveloper4 6y ago> Python 2.7.18, the "last" release of Python 2 Fix't it for ya.
- jillesvangurp 6y agoPython is currently one of the most successful languages out there. Most of the growth at this point is coming from python 3. So, from that point of view, it's been a huge success. If at this point you are still stuck on 2.7; you probably don't care a lot about updates in any case; including point releases. It's been well over a decade since it was made clear that this was going to end. So, IMHO the impact to remaining 2.7 users is minimal. They were in any case extremely conservative updating and are probably also running lots of other outdated stuff like Red Hat / Ubuntu versions that long dropped out of LTS, etc. That's fine and valid but at this point you shouldn't be surprised that you are on your own. If you didn't plan for this, that's on you. From a security point of view that just means you probably don't want to run unprotected 2.7 servers running e.g. a web server. But otherwise it's fine if you shield it a bit. Lots of python is more about other types of jobs where the impact of security vulnerabilities is much less. And, I'm sure that if there's demand, somebody might actually step up to do the occasional patch release if it is really needed. This has also happened in the Java world where several companies provide support for openjdk 6, 7, and 8 where Oracle no longer supports that (v8 stopped getting public updates already; you can still pay for some extended support but that too is being ramped down). I imagine, e.g. Red Hat might step up here as they seem to have continued to ship this for quite long and their LTS cycles might out run the python 2.7 cut off date.
- tempodox 6y agoMac vim(1) still requires Python-2. I'm not holding my breath.