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.
There'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.
Your 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?
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.
right 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.
How is a language supposed to make backwards incompatible changes, when it's eventually found that the original style contains substantial flaws?
Would you want the world to still be using K&R C? Because I remember the transition from that to ANSI C, and the special macros to make function prototypes work across both languages. The Python transition is little different.
It's called "moving forward". The technology sector moves fast, and you need to keep up. Nothing is ever going to get better with that sedentary mindset.
Well, if you ask me, backward compatibility should only be broken with extreme reluctance, because it's a huge waste of time to be rewriting things that already work. See also Angular 2.
This 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.
This 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.
That'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.
As 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.
You'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.
Python 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.
Man, 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.
A 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)
I 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?
The "ongoing official support of Python 2.7" is what resulted in the creation of Python 3. Python 3 contains the enhancements that are meant to fix the (very real) problems that exist in Python 2.
I really don't know where else you think those resources could have been used that wouldn't have resulted in Python 3. Unless you consider "doing nothing meaningful" to be a form of support.
I 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.
Python 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.
Language 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.
Well 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.
I 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.
Maybe, 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.
Some[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.
High 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.
The 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.
People 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.
Meanwhile 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.
If 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.
And 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?
A key point you ignore in my comment is the "caught at compile time" part. If generics breaks backward compatibility, but the breaks can be caught at compile time, upgrading a medium codebase may take only an afternoon, and that would be reasonable commitment. Huge difference from the Python 3 scenario.
Programming 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.
I don't understand this at all. Yes, you can add features, but if they are not ergonomic, then why bother? For instance, you can't just add features that introduce syntactic ambiguity or change your parser to become context sensitive without making the language significantly more complex all around.
Yes, you can add anything without breaking backward compatibility. That's why I qualified it with "reasonable" -- there are very good reasons to break backward compatibility, and being a slave to it will pile up technical debt in very unpleasant and potentially avoidable ways.
It's like trying to make a skyscraper taller without rebuilding the foundation. Sure, you can add giant ugly supports on the side, but once you've done that a few times, nobody is going to feel safe near your building. And no self-respecting architect would do it.
There is nothing stopping you from implementing a feature in a reasonable and ergonomic way without breaking backward compatibility. Programming languages are fun like that. Anything can be done, your imagination is your only limit. And on this level technical debt is not a concern, not even a little. But having good rationale for a feature is, and a huge one. Most of the time the authors themselves don't know why they need it, they just feel like having it.
There 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.
He 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.
I 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).
Actually, 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.
I have a reasonably large project that was started in late 2013 (so only 2.5 years ago) when 2.7 was already long "to be deprecated" but some of the key libraries used were not yet python 3 compatible.
I haven't actually checked, it could probably be ported now - but why would you do that now - everything can change in the next 3 years.
We're over the hump if something would change and still was python it would most likely be compatible with python 3.
There two things that might help you port things:
1. You can use Cython to mix python 2 and python 3 code together. You compile python2 code as a module and then reference it from the python3.
2. MyPy (http://mypy-lang.org/) - This might not seem like related, but if you provide information about types refactoring the code becomes much easier (like in statically typed languages) so when you change something it's easier to find all other places that also need to be changed.
Some IDEs (for example PyCharm) also understand typing which helps when using their refactoring functionality.
Are you talking about all the effort put into back-porting Python 3 features into Python 2? Or all the random threads attacking Python 3 developers for their unpaid efforts and initiative in making the language better? Or maybe you're referring to the 2020 deadline, which is tortuously long?
It'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.
And 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.
But 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
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.