7 ms·
Python 2.7 Retirement Countdown
- DasIch 10y agoThere are enough large organizations using Python that no doubt at least one will find it to be cheaper and more convenient to continue maintaining a 2.7 interpreter. Dropbox is working on one just to increase performance. PyPy also has due to how it works fundamentally a huge interest in maintaining Python 2.7 support for the forseeable future. You've to be quite naive to believe that Python 2.7 will retire in 2020. It will only fade from popularity slightly faster.
- sandipc 10y agoGuido van Rossum (Python BDFL) himself works for Dropbox, so I'm not sure I believe that... See also: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.pptx https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...
- DasIch 10y agoHe does but how much influence does he really have there? I doubt it's enough to push them to 3.x just because. Pyston 0.5, the interpreter developed at Dropbox, was also just released a few days ago. They're going to do what's pragmatic and cost efficient. Making everyone stop improving the product and porting the code base, is probably more expensive than just having one team maintaining and improving the interpreter.
- coldtea 10y agoYeah, don't hold your breath.
- CJefferson 10y agoNo, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.17.
- afarrell 10y agoHow many dependencies maintained by others does your Python 2.7 code rely on?
- ieverdream 10y agoright tool for right job :). You use python for specific purpose, if the Python won't be maintained anymore, you can keep the current compiler, so it doesn't matter.
- Svenstaro 10y agoYour C code might still work but are you not relying on any libraries which might have been updated in 15 years in a non-backwards compatible way and thus broken your build?
- CJefferson 10y agoIt's not perfect, I'll admit. I'm probably in a special area -- algorithms research. I tend not to use many libraries, and I'm often taking code written 10-20 years ago and wanting to get it working. The code is often VERY complicated, and I don't really want to reimplement it. Finally (and probably most importantly) I don't care about security holes, I'm not going to run this code on malicious input.
- StavrosK 10y agoMy python code from 2000 will be supported until 2020, so I'm not sure which language you refer to when you say it'll "break within a year".
- ben_jones 10y agoThere's something to be said about "small" languages. Whenever Golang does a point release I update all my production code without a fear in the world, not because I have to, but because their may be a performance improvement here or there that I get for "free". I think I skipped 1.5 and 1.5.1 because of a slight regression when they switched to a go-based compiler/runtime but other then that yeah, awesome. Conversely I'm always behind on Node as it's realllly annoying when a third-party lib breaks from an update. Larger packages will be fine but when you're dealing with say a Meteor package derived from an NPM package it's pretty shitty.
- Animats 10y agoThe amount of effort Python puts into screwing 2.x users is excessive.
- afarrell 10y agoIt's not that maintainers want to screw anyone over, it's that folks who give away labor for free to maintain libraries want to be able to use the new features in 3.x without spending additional unpaid labor to maintain separate 2.x versions.
- kinkdr 10y agoAnd vice-versa, it is not like users have some grunt against developers. They just don't want to go through the pain of having to migrate their applications and the instability that this will bring. (Disclaimer: I am not supporting any side)
- mfisher87 10y agoWhy does end-of-life mean you have to migrate your application? 2.7 isn't going to just go poof and self-destruct on your computer.
- kinkdr 10y agoI am not following.. Using the same logic they could have stopped support for 2.x the moment 3.0 was released.
- afarrell 10y agoBut they wouldn't be able to say "you should use python, we have all of these libraries!" Now, they can. There are a bunch of libraries that run under both 2.7 and 3.5, but they are doing extra work to make sure they work under both codebases and they are refraining from using any of the nice features of 3.5
- Retra 10y ago
- deleted 10y ago[deleted]
- omash 10y agoI'm hopeful we'll abandon Python 3 instead.
- Bromskloss 10y agoDo you like Python 2 better than Python 3?
- Svenstaro 10y agoCould you elaborate on that?
- jgalt212 10y agoMost everything good from Python 3 has been back-ported to 2.7. Except for built in parameterized tests in unittest. Python 3 has the subTest context manager (which looks great) https://docs.python.org/3/library/unittest.html#distinguishing-test-iterations-using-subtests https://docs.python.org/3/library/unittest.html#distinguishi... In 2.7 you must use pytest, ddt, nose-paramemterized or dynamically add test methods to a TestCase class at runtime.
- scrollaway 10y agoMost everything good? Like high quality unicode support and async def?
- jgalt212 10y agoSome[1] have argued that unicode is better in 2.7 than 3.X. Async looks very useful, though, so I'll add that to the list including the subTest context manager. http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
- Avernar 10y agoHigh quality unicode? Where every string with even a single emoji takes 4 times the memory. They should have used UTF-8 for their internal representation. Putting that aside, my issue with 3.X is that I have to use the unicode type even when I'm manipulating byte strings.
- scrollaway 10y ago> even when I'm manipulating byte strings What? No you don't. The `bytes` object is what you want when you deal with byte strings.
- Avernar 10y agoThe bytes object is not a string type. It's treated more like a list of integers. It has very little string operations. Only in 3.5 did they add back the ability to % format. Not to mention all the b prefixes it just becomes painful.
- Grokzen 10y ago331/360 of the most popular repos on pypi supports py3 http://py3readiness.org/ http://py3readiness.org/. Also python 3 support is increasing, while python 2 support is decreasing overall https://blogs.msdn.microsoft.com/pythonengineering/2016/03/08/python-3-is-winning/ https://blogs.msdn.microsoft.com/pythonengineering/2016/03/0...
- kinkdr 10y agoIs the list correct? It shows MySQL-python as 3.0 ready, but MySQL-python page (https://pypi.python.org/pypi/MySQL-python/1.2.5 https://pypi.python.org/pypi/MySQL-python/1.2.5) notes: > MySQL-3.23 through 5.5 and Python-2.4 through 2.7 are currently supported. Python-3.0 will be supported in a future release. PyPy is supported.
- Grokzen 10y agoThe tool they use to determine py3 support is the following: https://github.com/brettcannon/caniusepython3 https://github.com/brettcannon/caniusepython3 They have overridden mysql-python with mysqlclient https://github.com/PyMySQL/mysqlclient-python https://github.com/PyMySQL/mysqlclient-python
- kinkdr 10y ago> They have overridden mysql-python with mysqlclient I am aware of this, but the fact that the tool is reporting MySQL-python as 3.0 compatible, when it is not, is worrying.
- neokya 10y agoOverrides are mostly for drop in replacement. So you could use mysqlclient but chance very little in existing code.
- Scarbutt 10y agoDon't really like the tone of this, they are resorting to psychologically tactics now? (btw, I'm all in for pushing Py3)
- Bromskloss 10y agoMight this not simply have been made by someone who is tired of having to deal with Python 2?
- dkarapetyan 10y agoThis again? Python 2.7 is never going away, no matter how much people wish it did. Python is the Cobol/Java of dynamic languages. There is way too much volume of code written in it. This means there is a golden consulting opportunity for those willing to take it: support 2.7 code/libraries for money.
- StavrosK 10y agoThis again indeed, because Python 2.7 is going away. Python 3 is the future, and we've been resting on our "eh, python 2.7 is convenient enough" mindset for too long. We should just bite the bullet and move to 3, which isn't even that bad of a migration. Also, "supporting legacy code for money" is already everyone's job, unless you're implying that there are as many Python programmers as there are COBOL ones.
- tcarey83 10y agoPython 2.7 is not going away and why do you care anyway? People like you and the author of this website should just fuck off. People like Python 2.7, just let them.
- bionsuba 10y agoThat's incredibly naïve. Python 2 will be around and have new software written with it for at least a decade to come. Keep saying "Python 3 is the future", that will surely make companies invest in switching. Meanwhile ford still uses 40 year old IBM mainframes with COBOL, and will continue to do so until they are physically unable.
- asdfologist 10y agoYou've just proved his point by comparing Python 2 with 40 year old mainframes. There will always be users of legacy software, but that doesn't stop it from being, well, legacy software.
- cookiecaper 10y agoAs others posters have commented, Python 2 will survive in the sense that there will always be some code running on it (and there will be a niche market for dark artists who can massage it). Python 2 will not survive in the sense that no one will be writing new code for it. Python 3 is already commonly used for new projects and it's scheduled to get several big boosts in that direction as Ubuntu and Fedora switch to it as the default Python. The old meme that it's unsafe to use Py3 is not true anymore. Practically all of the big libraries work fine on Python 3 now. Py3 code is going to be dominant in new projects in short order if it isn't already, and it's plausible that new Py2 projects will be virtually extinct by 2020.
- unlinker 10y ago3 Years 10 Months 13 Days 20 Hours 54 Minutes 31 Seconds until a community fork occurs.
- takeda 10y agoI'm cool with it, as long as new projects aren't started in python 2.7.
- foxhop 10y agoI was going to say the same comment.
- cookiecaper 10y agoI don't think so. I know it's popular to hate on Python 3, but the community has not rejected Python 3, they've just taken a while to cozy up to it. The transition was always intended to be gradual (perhaps not this gradual, but still). At this point, the chicken-and-egg problem has effectively been solved for Python 3. Practically every major Python library has Python 3 support these days. The mainstream Linux distros are switching to Py3 as the default this release cycle. The largest remaining holdout will probably be PyPy diehards, but 3 years is a long time and I'm confident that the community's increased interest in Py3 will be made manifest to the PyPy development team in the not-too-distant future. I believe that the posted site is correct, Python 3's time is now. While there probably will be a fork specifically intended to provide security backports for legacy applications, I don't think it will see widespread use (the people who continue to run Py2 applications at that point will probably keep running the never-to-be-updated again CPython runtime).
- underyx 10y agoActually, it seems to me that everyone who is active in the community is already on Python 3 and is heavily in favor of upgrading. The people who are still using Python 2 are the 'lazy' ones, who don't really care about the community at all; the ones who keep making comments like 'I just use whatever the `python` command starts.' I'm pretty sure these people couldn't maintain Python 2 by themselves.
- 10y ago
- fallenshell 10y agoMan, the amount of people and support going for Python 2.7 is mind boggling. Coming from another language, I find the slow adoption of Python 3 insane. Don't you want Python as a language to advance? Python should've abandoned and deprecated 2 ages ago. I still see new tutorials teaching 2. What the hell.
- deleted 10y ago[deleted]
- shadowmint 10y agoA lot of people really dont care about the future of python, they just want to write code. ...and honestly, whats wrong with that? really, what difference does it make if people use old python versions? Other than the core python team, which get to be embarrased that many people have zero interest in the work theyre doing? Does it affect you? nope. Does it break the ecosystem? nope. Does it make library authors suffer? nope (dont support it if you dont want to). Come on. Live and let be. If you love python3, use it. Dont winge pointlessly (not you personally; all the hostile frothing at the mouth python3 advocates, especially on reddit)
- asdfologist 10y agoI think you missed the whole point of this thread. People want ongoing official support of Python 2.7, which involves resources that could be used elsewhere. Supporting stuff is not free, you know?
- shadowmint 10y agohttps://hg.python.org/cpython/graph https://hg.python.org/cpython/graph I guess you can decide for yourself if the 'official support' of python is a massive drain on resources that could be used else where. (The red line with a few commits now and then is the 2.7 branch)
- asdfologist 10y ago
- deleted 10y ago[deleted]
- altano 10y agoI just recently started learning Python for the first time, and at some point I switched from playing with 2.7 to 3.x, and my uninformed opinion is that I'm shocked at how many seemingly completely unnecessary breaking changes there are. Did the parameter names to open()d really need to change? Why did I have to change from io.open() to open() for a stream? Did str.lowercase really need to become string.ascii_lowercase? The number of errors in my toy little program upon upgrading really surprised me.
- zzzcpan 10y agoLanguage changes rarely make anything better or even worth doing. But they are very easy to do and so they are the things language developers usually want to do and want to play with. Asking the hard questions will only make you disappointed in them.
- forgottenpass 10y agoPython 3.0 was basically a line in the sand to throw in all these "unnecessary" breaking changes. At the end of the day, no changes are actually necessary. But to keep Python improving without weighing itself down, some changes couldn't just be slipped into the 2.x series. Because they're fundamental enough changes to even effect toy programs. So, yes, I'd say that the default string type did need to change from bytes to unicode. And not only do I not miss str.lowercase, that kind of vestigial feature is exactly the type of thing that should be purged with the unicode transition.
- asdfologist 10y agoPeople here keep bemoaning the golang designers' decision to not upgrade their language with things like generics, but suddenly their panties get twisted in a bunch when the Python community actually decides to fix problems in their language. Get off your high horse and upgrade your code. So many people did it before you, and so can you.
- shadowmint 10y agosuddenly? you mean 7 years ago? This is an old pointless fight. :/
- BigJono 10y agoMeanwhile in Javascript land, if your code is a year old you're already running out of prospective hires that are familiar enough with the language to maintain it haha.
- netheril96 10y agoIf Go upgrades itself with support with generics but break backwards compatibility in a horrible way and the breaks cannot be caught at compile time, people will be complaining and resisting upgrade just the same.
- Retra 10y agoAnd what should the Go team do if the only reasonable way to add generics is to break backward compatibility? Just rip the bandage off? Stagnate? Abandon the language and start a new one?
- zzzcpan 10y agoProgramming languages are not like that. There is an unlimited amount of ways to implement a feature without breaking backward compatibility. Perl, for example, at some point kept compatibility even with bugs, because many people were relying on them.
- 10y ago
- iconjack 10y agoWell I'm sure this is a naive point of view, but I'm going to put it out there anyway. It seems there are many Python devotees out there who are lukewarm about Python 3, and quite a few who really don't like it at all, hence a slow adoption rate. Right now it seems like the community is fractured along that fault line. Is it too late? Can we back out of the current incarnation of Python 3 and go down another path instead? In other words, turn the slow adoption rate into a plus, call a do-over and mold the new Python into something more people are happy with.
- nerdponx 10y agoAs someone who learn Python 3 first, I'm amazed that people really think Python 2 is better. After so many years, why the resistance?
- iconjack 10y agoI hope you didn't read my comment as saying Python 2 is better. Personally I don't have an opinion on that. But as you can see from this thread and many, many others, a lot of people are disappointed with Python 3's choices. You're right, it's been a lot of years, but if adoption has been as slow as some are suggesting, maybe we could cut our losses and put our beloved Python on a different path, as a community.
- nerdponx 10y agoMaybe, but at the same time I haven't yet seen a criticism of py3 that wasn't just a litany of complaints about backward compatibility. Even in this thread, I don't see a whole lot of substance behind the discontent.