Extend Python 2.7 life till 2020
hg.python.org
hg.python.org
The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed.
What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027.
Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do.
An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL.
Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.
So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7.
The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.
[0] http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...
> Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.
Note that 2.6 had no installers released beyond 2.6.6 (2.6.9 was the eventual last release), so there's a precedent for source-only releases if nobody does want to provide Windows/OS X installers.
10 years actually. This is a common misconception from those who do not read the lifecycle page carefully.
When I first learned Python, I learned Python 3 first because it was newer, and I figured everyone would be using it soon enough. Little did I know that Python 2 would continue to be supported for over ten years after that!
Some people make a big deal about figuring out "which" Python to learn - that's not really much of an issue, because Python 3 isn't so different from Python 2 that it's hard to pick up the other very quickly (especially given how much has been backported to 2.7). But it's unfortunate to see people continuing to write new code in Python 2.
But, I have to say, that during the keynote by Guido this morning, this was more-or-less the sentiment that I was left with, but with a #positivepython-twist.
Listening to Guido, I left with the inspiration to try and help this community make that migration.
I hope that, by this time next year, I can have made some contribution to the community that will help people such as the GP be in a position to use "the latest and greatest".
Here's the list, let's make it green:
I assume there is a good answer for switching to Python 3, but I honestly don't know (haven't bothered to do any research though).
Harshly put: I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't care less for the Python language and it's future.
I rarely write anything high language besides small scripts. Python 2 does the job. If I ever were to need functionality of another language, great, it's fun to learn something new. Our time is limited and we must prioritize. Sadly we cannot invest time to learn everything (well I guess it's possible, but I rather be awesome in four languages than mediocre in twenty).
You admit you haven't done any research, so you clearly don't have any basis for making that statement.
Python 3, scala, and pearl all give you new ways of solving a problem. You're missing out on a lot of super cool stuff by not exploring! Outside of maybe library support, I see no reason to not to at least check out python 3.
>I rarely write anything high language besides small scripts. Python 2 does the job. If I ever were to need
>functionality of another language, great, it's fun to learn something new. Our time is limited and we must
>prioritize. Sadly we cannot invest time to learn everything (well I guess it's possible, but I rather be
>awesome in four languages than mediocre in twenty).
Just so you do know what the story is with python3: It's mostly a move to proper unicode support (which couldn't be done without breaking backwards compat) but it's a relatively minor change for most code. You'll definitely run into some library support issues, but they should be few and getting fewer. It shouldn't be terrible, and I'd encourage you to do it just for the sake of Guido and the python community, because this transition has been a bit of a burden for them.
Guido just created a bigger problem. No good deed goes unpunished.
In fact there'd be "tens of thousands" websites made with Python alone (Django et al), so the number of apps in total will be much higher.
Heck, people doing scientific Python are more than 10.000, and they write more than one new apps for their research every year.
I just dislike how melling basically pulled a number out of his ass, and then used it as "evidence" to back up his claims. I wouldn't even consider it a low-quality estimate, since he doesn't even try to justify or explain how that number was obtained.
In this case, "tens of thousands" could very well really be "hundreds of thousands". It could be significantly less, too. Regardless, it's purely speculative. Using such made up numbers makes his argument weaker than perhaps not using any such value at all.
Obviously, if people were moving more quickly there wouldn't be a need to push out 2.7 support until 2020.
If only there was a way to deprecate a language, with the same meaning as deprecating an API method: "it's not gone yet, but it will be soon, so in strict mode using it is an error." (The main problem to solve would be: strict mode of what? The package manager?)
One way that usually works is to release a newer version and stop updating the old one after five years. Oh wait...
This shows a serious disconnect from reality. Discontinued support for Python 2 was never a major reason to move to python 3 for apps. Library support is WAY more important in the choice to switch. If all of the libraries worked with Python 3, there would be no reason for app writers not to switch.
Unicode
And of course, you'll move from a platform that's shutting down to one that's evolving
Really, it's worth it.
Potentially no new libraries (for new things and/or API connections)
Not sure how long new versions of existing libraries will keep 2.7 support.
If you prefer to have no Google App Engine, Azure, Amazon or distro support other than Arch, then have at it. I'll keep that and PyPy, Pyston, Jython, IronPython, PyInstaller, not to mention all programs where Python is integrated like GIMP, all of this is Python2 only.
Enjoy your Python3. I'll stick with Python.
If you can live with that, then by all means stick to 2.7 until your Red Hat support contract expires. If not, consider switching to 3.x.
No new features, no improvements, nothing -- just the same language, for a decade.
Or a good, supported, still used and very stable language: Fortran.
The only pain point is Pascal's lack of a nice-sized community (and thus libraries, support for modern systems etc) nowadays.
(Obviously, if you said, e.g., Fortran 77, the story would be different.)
This is not ADD, this is not rudderless. This is preferring actively maintained and improved things over old crap that never gets fixed
But that's OK, because 2.7 is exactly for the people who have to maintain old 2.x projects and people who never want Python to change again (and will just move to Rust or something soon anyway, instead of learning and using features in Python 3).
This bothers/worries me, because I don't understand where this notion that "learning Python 3" requires significant effort or commitment comes from. Python 3 isn't massively different from Python 2. I learn more "new stuff" (APIs I've never used before, implementation details of systems I work on/with, etc.) basically every month than that difference.
Python 2 -> 3 can be a big step because of dependencies. The difference between the languages themselves is negligible (and yet, IMHO for the better). You don't need to learn any new ways of thinking here.
If you're comfortable with Python 2, you're comfortable with Python 3 as well. If your dep ducks are in a row and you're writing new code, it's an obvious choice.
I use Python 2 because of the massive ecosystem of libraries that have been written, work, and will continue to work.
It's shortsighted and more than a little irresponsible to shame or muscle people into switching. Code that works is valuable. Code that has been tested for a decade is valuable. What's not valuable is forcing an upgrade to a platform that nobody wants to upgrade to while forcing us to abandon third-party code with years of field testing that the authors aren't ever going to port to python 3.
It was for the OP. Can't fault me for my reply not reading on an argument you make after the fact :).
> I use Python 2 because of the massive ecosystem of libraries that have been written, work, and will continue to work.
I too like useful libraries that save me time and effort, and I agree that Python 2 is extremely strong there. I feel like Python 3 is catching up and has a pretty good library story going for it already (my gratitude to those who make that happen through their contributions), in addition to being a language I find more enjoyable and productive to use than Python 2.
> It's shortsighted and more than a little irresponsible to shame or muscle people into switching.
I don't think I've done either, and I think you're being quite rude here. I was merely voicing my opinion that the magnitude of the differences between Python 2 and 3 gets blown out of proportion. Please be mindful of the context.
> that nobody wants to upgrade to
Not so, I've wanted to and have upgraded things to Python 3, and so have others.
As for the whole "forcing" stuff - well, yes, it happens. As a user of a language you're part of a community, and communities can sometimes decide to go into a direction you don't agree with. It's frustrating and difficult, and you can reasonably decide that it's a deal-breaker and leave the community. Often however it's valuable to instead put one's efforts into achieving consensus, and then defending and carrying that consensus, even if it's not what you originally wanted - shit tends to get done faster then, to the benefit of all.
The parent poster wasn't concerned about learning the language. They were concerned about dependencies that work, which is what I was saying:
"I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't care less for the Python language and it's future."
Yes, I didn't mean "nobody" literally. I should have said "few."
No, read more of the thread - to quote the OP:
> I rarely write anything high language besides small scripts.
OK, so you could argue that their scripts probably remain small because they call into tons of third-party code, but honestly I get the impression that it's a case of working with the included batteries and not being overly concerned with dependencies. If it was solely about deps availability, they probably wouldn't have talked about "learning Python 3" as their sticking point.
Nobody who's making anything that actually matters and delivers value to customers cares about the improvements in the language itself as much as they care about the battle-tested libraries that come with that particular language.
If you are a company that actually matters (has significant growth / users) and you use Python3 over Python2 as the main language in your stack, I'd like to know who you are, if you even exist.
I'm not asking as a challenge to you, I'm genuinely curious.
Now If I had stayed on 1.2, then many of the extra libraries I am using or looking at these days would not be compatible. (Now sometimes I want to use older libraries that have not been kept up to date, but the more popular packages which gain traction - the "more important ones" tend to keep up to date or replaced by ones that do).
A language is different from a framework, but I assume once enough traction is gained, then the same thing will happen with Python - popular packages will end up up on Python 3 only. There seems to be a fair bit of 'push' from the community for people to move to Python 3, with comments of "why not change already".
In what way is python 2 more convenient to write? Outside of the rapidly shrinking set of cases where the best approach to a key problem is addressed by a Py 2 only library -- or the case of "I want to deploy on Google App Engine" -- I don't really see how Py 2 is "more convenient".
Because python 3 was not the most stable at the time of distribution of that operating system. Why would I the developer of said operating system release anything but the most stable versions of the language? This would in turn make my operating system at times less stable.
She's ok with the occasional "sudo pip install ..." to get a library, but if my instructions started with "ok, first install Xcode and then install homebrew" the answer would probably be "it's ok I'll just do it by hand"
Its not that difficult.
Arch comes with Python 3 as default.
print(x, end='')
Yes, its a function not a statement, so its now print(x).
> which also gets rid of "print x,", which printed something without making a newline, for one thing.
Sure, you have to do: print(x,end=' ')
if you want to space separate things printed on separate code lines on the same output line.
Of course, if the extra keystrokes bother you, its really not much one-time cost to toss together a library that provides a function that gets rid of them, while keeping the rest of the power of the print function:
def p(*args, **kwargs):
kwargs = {'end': ' '}.update(kwargs)
print(*args,**kwargs)
def p(*args, **kwargs):
kwargs = {'sep': ' ', 'end': ' '}.update(kwargs)
print(*args,**kwargs)
import functools
p = functools.partial(print, sep=' ',end=' ')- "Ugh, that thing is lacking/stupid/messy."
- "Oh, no problem, that wart has been fixed in Python 3"
- "Can we use it?"
- "No."
It's a real pain in the ass when I try to publish my own, though. The generally accepted rule is that all libraries must support 2.6 through 3.4, and this can be a major hassle.
I'm not sure if it was something I did but I also occasionally found that when pip'ing Python 3 libraries with a lot of dependencies, occasionally some of them would actually be Python 2 libraries and things would break.
This isn't disappointing, it is refreshing. Python is dead, long live Python.
Your argument is right, but they should have thought about that before fracturing the python community.
The Java model of using separate lifecycles for the runtime/JVM and the language itself is probably a good role model for the future; it allows introducing new language features without any danger of creating library inconsistencies and allows specifying source and VM versions individually.
Python 3 didn't offer anything that would have been so useful and desirable that people would've jumped on it the moment it was released. In fact, it was actually a bit worse than Python 2 when it was out and those Python 2 users could continue enjoying loads of libraries to go with, and of course they knew how to navigate around Python 2's quirks so why bother. Sadly, this is still what I think of Python 3: "Why bother?".
Python 3 didn't have enough to warrant a 'v3', really: Python 3 could've just been Python 2.7 if it wasn't for the religious backwards compatility in Python, which, ironically seems to matter a lot. The syntactic and semantic differences weren't big enough that Guido couldn't have worked around the most important improvements into 2.x line and dropped less relevant stuff (like removing 'print' statement etc).
Even if Python 2.7 would've needed some changes to existing libraries, the psychological barrier would've been lower. It's about "Fixing my lib to work with Python 2.7 which is top of the line today" versus "Porting my lib to Python 3.0 which will be the official Python in a few years": guess which one sounds more appealing? Note that the amount of work in both cases wasn't that big.
I think mainstream Python will be 2.x till Python 4 is out.
The Unicode switchover is where all the pain is, and it isn't particularly clear that there is a good way to do such a thing.
But least for smallish scripts which print a lot it give you a better overview because the print line look different than other lines. Sometimes prints can almost be like comments.
2.x didn't have a print function, unless you mean the one from 3 available with a from __future__ import.
I agree with the sentiment, and 3.2 had some rough edges still, 3.3 is better and 3.4 finally gives a virtualenv similar (or even better) to Python 2
It still has a few things that really suck!
The thing that bothers me the most is the removal of in-argument tuple unpacking. For example, in python 2.x you could write:
dist = lambda (x1,y1),(x2,y2) : math.sqrt((x1-x2)2 + (y1-y2)2)
Whereas in python 3.x you must write
dist = lambda p1,p2 : math.sqrt((p1[0]-p2[0])2 + (p1[1]-p2[1])2)
Which is just awful to read. It gets much worse when you're trying to program in a functional style and you are using triples or quadruples. Imagine using "x[1], x[2], x[3], x[4]" instead of something like "length, width, height, color".
PEP 3113 attempts to rationalize this change, but it's kind of an awful PEP. It claims "no loss of abilities removed", which is clearly false, and the proposed benefits are highly specious. The entire tuple-unpacking system could just be reduced to the insertion of an unpack instruction at the start of the function. That would actually make a lot of sense with Python's policy of "ask forgiveness rather than permission", since trying this with the wrong tuple length would throw a ValueError explaining what went wrong.
I also miss (but it's not really an important language feature like in-argument tuple unpacking) the ability to do encoding directly on strings. For example,
"hello".encode('hex')
or
"aGVsbG8=".decode('base64')
That was much more convenient than having to import some library and use library methods.
So this isn't really making Python 3 any less appealing. But the Python core developers cannot with a calm heart abandon all the users of 2.x, given the state of adoption today.
And if I look at the whole thing now, "no new features" is not certain. If people are still unwilling to switch he may consider backpedaling and backport some other features to 2.X.
I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge.
Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.
I think, many more projects would have adopted Py3, if more extension modules would support it.
The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.
I mean a hard difference between a string and bytes and strings being utf-8 by default seem to be a necessary (and good) reason?
Am I missing something here?
Maybe py3 just doesnt have good enough features compared to 2 for people to make the switch and shouldnr have existed in the first place?
But gradually introducing changes.
Now python is for all intents two languages instead of one.
Python2:
print(1/2 * 1000) # 0
print({b'a': 'bytes', u'a': 'text'}[b'a']) # text
print(b'A'[0]) # A
print(1/2 * 1000) # 500
print({b'a': 'bytes', u'a': 'text'}[b'a']) # bytes
print(b'A'[0]) # 65
Most of the numbers I encounter start as integers and most of the calculations I need are floating-point. This language behavior saves me from sprinkling "* 1.0" everywhere on my code, or from introducing extremely subtle bugs.
And the integer division is always there, one character away:
print(1//2 * 1000) # 0The Python3's operator '/' (on numbers) is defined to return a float, and it'll convert any integer parameters as required. The same is true for other operators, like 'True + True' being 2.
Because of these definitions, you should consider the operators as explicit conversions. 'total / sum' is less explicit than 'total / float(sum)', but still clear enough.
And about guidelines, there are others that fit this case:
Simple is better than complex.
Flat is better than nested.
Readability counts.
[...] practicality beats purity.
I went to check out the operation and it seems a on two ints returns an int if the power is a nonnegative int, and a float if it's negative nonzero, in both 2.7 and 3. I didn't expect this kind of inconsistency from python, really.
>>> type(2 ** 1)
<type 'int'>
>>> type(2 ** -1)
<type 'float'>
But if I was writing it I would space the "1/2" into "1 / 2".
The first says half to me (ok, until I pause and realise it is code I am interpreting), while the second is 1 divided by 2.
import2.7 modulefoo
And it's not just a matter of sacrificing core dev hours for the greater good, the result would be much slower and full of gotchas.
This is a very creative idea, ingenuously simple, but I don't think it would fly.
Solutions might include adding some sort of hinting to specify the conversion, or add a Python2-like string class to Python 3, which would pollute its purity.
#! /usr/bin/env python2
vs
#! /usr/bin/env python3
Python allows you easily to run different versions side by side. There's really no good excuses.
Red Hat is major reason why the migration is so tough. They still ship with Python 2.6.
Then, without the fancy v2-to-v3 bridge, it wouldn't really be more useful than just having both interpreters installed separately.
The fancy bridge does sound like a cool idea. We can run Python 2 or 3 code from Julia (with limitations on the data passed between them), so why can't we run Python 2 code from Python 3, with the same limitations?
It's basically possible already with some RPC libraries, but the experience could certainly be streamlined.
The problem with 2.x scripts is that they mix characters with bytes quite often. This is not something that you can easily fix by a program, because from this perspective 2.x programs are broken and need to be fixed.
What you are suggesting is already available, python 2.x and 3.x can be installed and work side by side without any issues. There's even 3-to-2 conversion tool (converting backward is much easier than the other way since python3 is more strict).
The problem really comes down to distribution maintainers, for example we are talking about Guido extending support from 2015 to 2020 for Python 2.7. So before this announcement, Python 2.7 would no longer be supported in 2015, yet we have geniuses at RedHat still shipping it with Python2.6.
And no, there is no incompatibilities between 2.6 -> 2.7 as there's from 2.x to 3.x
The Δ between Python 2 and Python 3 was just too wide. Even with breaking changes, with a small Δ people will just migrate eventually. Migrating projects drag each other over the "barrier" just like water in a hose can be sucked over a wall.
The issue definitely was not the print command, but other things such as ``iteritems()``, etc - by themselves not much to keep you from migrating, but there is a pile of these boring changes next to the big one (unicode).
I think Guido overestimated the appeal of the new unicode handling and underestimated how resentful people are to change. I figure that at least 1/4 of programmers are actually very opposed to each and every migration and a new version has to have enough incentives to counterbalance this built-in conservativeness.
I'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use* haven't been converted to 3.x. I like the language, but ... damn... If it weren't for the scikit/numpy stuff, I'd stick with Ruby. The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases.
edit: * By that, I mean that the conversion rate for commonly used libraries hasn't hit 99%.
As far as specifics, one of the first tasks I wanted to perform was to survey some of the NoSQL databases with some test cases that I would build in Python.
Mongo had a good 3.x driver and I worked with it. Great... but then these drivers all put me into a brick wall trying to use 3.x: couchdb, pycassa, happybase, and cql. There were numerous others that I tried along the way, but I don't have notes on all the failures.
Now, rather than trying to be 3.x pure, I don't even bother checking. I'm just using 2.7 for this project.
Python is the least special component in the mix and I would be very reluctant to have to upgrade everything just for 3.x.
You kind of answer your question you know, the reason why Python is so fragmented wrt Ruby is precisely because it has a much larger number of uses case: scientific (numpy/scipy/panda), sysadmin, web (django, bottle, ...), games (Ren'Py, ...), etc. Ruby on the other hand is pretty much just Rails[1]. It doesn't make Ruby a bad language, but then it's a lot easier to handle the migration.
[1] Yes, Ruby can also do games and statistics, but AFAIK, it's nowhere near as much used as numpy is to Python.
Also don't ignore that Ruby has a _huge_ subcommunity in asia that you rarely get any news from, using the language for many other things.
Still, an aggressive push towards the future is part of the Ruby mindset. If your lib doesn't work with Ruby 2.1, it is not considered maintained. That helped _a lot_ during the 1.8->1.9 transition, which was basically Rubys Python 3 moment. The Ruby community managed to cross that bridge.
Puppet and chef say hi.
(And Chef is part Erlang...)
That being said, my point wasn't that there are no software outside of Rails, that would have been quite a claim, but rather than Ruby is much more defined by Rails than Python is defined by Django, which is why migration which alway be much more difficult on this side of the animal kingdom.
My organisation has a massive internal platform, with hundreds of applications all developed in Python 2.6. We are in the process of upgrading the base platform to 2.7 but I believe we will never be able to upgrade to 3.x. We have hundreds of thousands, perhaps millions of lines of Python code and it's growing all the time. When we started the project version 3 wasn't really a practical option.
Yes, the Ruby 1.9 release broke backward compatibility and there was quite a time when lots of Ruby stuff was stuck on Ruby 1.8 and you saw much the same stuff as Python 2 to Python 3.
Indeed, one of the big issues was a major change in string handling (to encoding-aware strings), just as with Python.
It resolved more quickly, but I think that's largely due to the fact that Ruby had less diversity of libraries that were critical in one domain or another than Python, and thus less holding it back from changing over. Python has been something of a victim of its own success here.
The worst thing to me about this transition is what it says about updating existing languages. Python 2 to 3 wasn't that large, really, and look at the resulting screwup, still ongoing. I was on the pro-Python 3.0 side (though I had 0 influence on the decision) and honesty compels me to admit that I never dreamed that it would go down like this. I never would have been pro-3000 if I'd known.
Anyhow, to anyone who has ever read about Go or Clojure or Nimrod or Rust coming out and asked "Why do we need another languge?", the answer is: "Look at Python 3." If you want to tweak anything about an established language, it's almost easier to "just" bring up an entire new language and stack than to fix the old one. And unless our existing languages are Practically Perfect in Every Way... and they're not... we need fixes, which means we need new languages.
So maybe it's only when you want to do something as invasive as switching the default string type that things go so sideways, if that is even the right description for Python 3 (which I think you could argue was really about having a better language available in 2015 or 2016 or so, not just being the Python after 2.7).
Compare this to a language like golang, where you can just run "go fix" on your code to update it to the latest version. And you don't have compatibility hell, because when you distribute your application, it's a standalone binary. Stuff like go is the future. Get off the dynamic language hamster wheel.
It seems to be that automatically upgrading your code, even with "go fix", is staying on the hamster wheel. Using a stable language like Python 2.7 is getting off the hamster wheel, since the "hipster" programmers (including me, sometimes) have moved on.
So in a way, Python 3 helps you if all you care about is stability, since people will make changes to 3 and you can keep using 2.7.
There is also the issue of how code gets installed on the system. The Python model is that you have a bunch of py files sprinkled throughout the filesystem. In this case, you have a "baling out the ocean with a teaspoon" issue when making a major change. There has to be a flag day when everything changes at once. In contrast, with Go, I can have apps compiled with Go 1.0, Go 1.1, and Go 1.2 co-existing happily on the same system. They don't share library files. (Yes, I understand abut things like virtualenv, but that doesn't help distributions that want to ship your software.)
A big part of why Sun (and now Oracle) has been so conservative about backwards compatibility in Java proper (as opposed to the libraries and ecosystem) is because JDK upgrades have a similar "baling out the ocean with a teaspoon" property. It's all or nothing... you generally only have one version of Java installed, and it has to play nice with everything. If they had integrated the runtime into the binary like Go did, this would be much less of an issue.
What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.
The Java designers wanted jars to be runnable by any virtual machine, ever. This meant preserving some pretty old and nasty hacks (like erasure for generics) to allow old jars to work with new virtual machines.
With Go, you would just recompile and that would be it. Go doesn't even support loadable modules yet (although it's coming soon), so they can do whatever they want with compat. It's unlikely they'll make the same mistakes Java did because they are not blinded by the "write once, run anywhere" ideology.
Could dynamic languages avoid this by having (say) a byte-code compiled backwards compatibility module? I would imagine it looking something like this for Lua:
luac -version=5.0 module.lua -o module.o
and then call into whatever functions you need from module.o in the rest of the project, using the new interpreter for whatever doesn't need to use legacy features.
Java hasn't really acquired that much "cruft." The cruft that it does have is mostly relics of really poor design decisions that were made (again) on day 1. For example, the decision to support thread cancellation, which the designers later realized was dumb, has left a bunch of defunct APIs in the Thread class which you're now not supposed to use. I already talked about how the need for jar compatibility (due to the misguided portability religion) led to the generics issues. Java is an ugly language in some ways, but you can't really say that it degenerated: it was that way from the beginning. In fact, now is probably the prettiest it's ever been (not saying much).
Most of the py3 wall of superpowers is now green (https://python3wos.appspot.com/) with boto, mysql-python, nltk, python-openid being some of the rare few in terms of not having great py3 alternatives. And most of these have ports on the way already.
So one interesting effect of this is that now that there is some critical mass and people are starting new projects in python3, there is now pressure on package maintainers to have py3 ports. So it's users dragging the packages forward now rather than the packages dragging the users backwards.
The list is still too long.
* portia doesn't work in 3.x because of scrapy, twisted and scrapely;
* psdash - developers don't care;
* jasper-client - developers don't care;
* ansible - Paramico was not ported when development started, now it is a big task to port ansible;
* scrapy - depends on twisted;
* heartbleed-masstest - developers don't care;
* planout - developers don't care;
* beets - not sure what's the reason, either some dependencies or developers don't care;
* reddit - no reason to move for 3.x for a large codebase which is not a library;
* salt - docs says it needs Python < 3 (maybe the reason is similar to ansible's);
* pacemaker - developers don't care;
* pyjvm - developers don't care;
* sentry - large codebase which is not a library.
That's not bad (12 trending packages have 3.x support, 13 don't). But clearly something stops some new packages from starting in py3, and many packages that people find interesting don't work in 3.x. I think that the only way to improve this is to help porting "base" packages that ecosystems depend on; just providing alternatives is usually not a good answer.
Twisted and Scrapy are getting ported, and the community is moving forward. But this is not happening because of a miracle - people are making it happen. My point was not that Python 3.x is bad (I think it is good), it was that community still needs help, that writing alternative software is not the best way to do it, and that there are still reasons why writing new Python 2.x code is easier.
Praising 3.x won't make users switch if they need some unported package, and bashing 3.x won't make other people's lives easier either. So let's help twisted, scrapy and other modules to become 3.x compatible.
Scrapy reached an important milestone recently - its test runner can now run tests under Python 3.x; test runner was the main reason why porting haven't really started before. If anybody wants to help then ping me kmike84 at gmail.com, or check https://github.com/scrapy/scrapy/pull/682, or go to ScrapingHub booth at PyCon and talk to people there.
https://pypi.python.org/pypi/paramiko/1.13.0
Fabric won't be far behind after this.
I suppose they're not officially releasing it because there may be some unloved corners of the library that don't work yet on Python 3. But everything I've done with it has worked fine.
Issues that prevent a release are not related to Python 3: check https://github.com/nltk/nltk/issues?milestone=2&state=open, https://github.com/nltk/nltk/issues?milestone=3&state=open and https://github.com/nltk/nltk/issues?milestone=1&state=open.
PHP 4 to 5 was a massive leap compared to Python 2 to 3, but they actually made that leap!
He didn't take the decision lightly. These are just two examples, but there's still lots of big Python 2.x uses out there.
If it's any consolation, his keynote started with a big "forbidden" sign over "2.8".
However, nobody noticed because nobody used the OO features in PHP4.
The difficulty of upgrade for PHP didn't come from the devs having to redo / revalidate parts of their code for little to no immediate benefit (like in Python's case) but in the shared hosting companies (un)willingness to make the upgrade when the scripts their users wanted (phpbb, wordpress, ...) worked fine with PHP 4.
And that's why these various projects agreed to a common date of "end of support" for PHP 4, sending a message to hosting companies to either upgrade, or not be able to deploy wordpress and co anymore
In PHP 4 for example you had an object model where the constructor was a method named alike to your class. In PHP 5 you got the __construct() magic method, but as a fallback, the method named to your class still works as constructor.
The same holds for properties defined with var instead of public/protected/private. For compatibility again, the var keyword is just interpreted as a public property.
As a third example, PHP5 came with an OOP system with support for interfaces, abstract classes and the final keyword. In PHP4, this wasn't available. So, there is no PHP4 code which uses these concepts, making them work in PHP5 as well. Obviously, this doesn't work the same way around.
There are some backwards compatibility issues, but these are minor in contrast to what you probably had written in PHP4 back then [1]
Now, for Py2 vs Py3 this is a completely different story. Py2 code doesn't run automatically on Py3. See this answer [2], as there were so many porting issues developers didn't had the time to overcome the overhead just to port the code. So: no, you can't compare the PHP 4 > 5 change to the Py 2 > 3 change.
[1] http://www.php.net/manual/en/migration5.incompatible.php [2] https://news.ycombinator.com/item?id=7581584
There were a few reasons why they pushed harder with PHP5 however, especially given the tendency of budget web hosts to use old versions of PHP4 with insecure by default configurations (register_globals etc.).
That may have been true of Python 3.0 vs. 2.x, but Python 3 has moved forward quite a bit since 3.0.
e.g.:
* Performance
* Getting rid of the GIL
* Improve multithreading (somewhat related to above) - multiprocess is still very bad performance-wise
...and therein lies the difference.
Yeah. But only because they rendered the old websites in various quirks modes[1] that emulated the rendering engines of the old web browsers.
Thankfully, web browser developers did not share the analagous mindset to the people saying 'lets stick with python2-compatible semantics forever', or we'd still be writing sites that had to be backwards-compatible with IE6, instead of having the option to specify a modern doctype and use IE6-incompatible markup (the analogy to using a python3 shebang line and writing python2-incompatible code).
The sites worked. Quirks mode is now being phased out, but it served its purpose. The analogy Im making is obvious:
Python 3 should have run python 2 code and slowly rolled old semantics into depreciation; this whole mess could never have existed.
Its not as simple as 'just port your code and run python3'
There also isn't really anything as drastic as the bytes/strings/Unicodes left to change.
(But these are better answers to worries about Python3 than they are answers to porting 2.x code bases)
If I switch to anything, I'll probably switch to Go.
(I originally typed 2.7, which is nonsense.)
Personally, for me switching to 3 is a massive hindrance and probably I'll never do it. For the kind of things I use Python, the changes are extremely significant and it actually seems to me like a step backwards. It may be an improvement in other respects, though. I don't know.
I think this is what is often happening, given that Go is attracting more Perl/Python/Ruby types than its original target audience of C/C++ developers.
Python 3 compatibility far outnumbers incompatible packages now: http://python3wos.appspot.com
(That doesn't make it hard or anything, but it seems lots of projects that depend on it were waiting)
https://github.com/boto/boto/issues/1127
and also the py3kport branch:
It's not like I can just decide to drop the dependency on boto and twisted from all my work code and migrate to something else.
I understand that these are opensource projects and I should be submitting patches to make the migration faster, but from a business point of view, I have absolutely nothing to gain by doing that instead of just sticking with 2.7.
and Twisted seems to be making good progress:
People won't leave Python 2.7 for Python 3.x, they'll go to other languages. Python has no right to its users.
I don't know what you mean by "I didn't find it simple ....". I googled "python 2 und 3 differences", and that was the first result.
Cede control of python 2.x to vendors who continue to demand support and bug fixes?
That would be a disaster; it'd be a moment away from new features and a 2.8 'cant believe its not python'.
I'm still writing lots of code with it and even quite a lot of new code. It's been around for ages and it feels like almost no libraries have been ported to 2.x yet. On a couple of occasions I've started a project with Python 3.x just to drop it or move to Python 2.x as a library I need doesn't seem to exist for Python 3.x and I don't want to port it over myself. I've never had this issue with 2.x (no libraries support 3.x only.)
Most Python 3.x "killer features" have been back-ported to Python 2.x and I honestly feel little reason to upgrade myself now. When support for Python 2.7 is officially dropped we could fork it and continue. I would hope it wouldn't take huge amount of effort for some people to support it? Just fix bugs and security issues and take pull requests? In that way might Python 2.x even outlive Python 3.x or at least remain more popular?
My guess would be that Python 2.x will die at the same time that Python dies, i.e. the "transition" to Python 3 will never really happen, and part of the reason that Python will die is the split between 2 and 3.
I don't think it was obvious that Python 3 would "fail" in this sense, but it seems pretty likely now. Sympathy with Guido; this is essentially a cultural problem rather than a technical one, but as a rule backwards-compatibility tends to be a key component of success as a programming language (or library, or even O/S) evolves.
It's not too late -- a compromise could be found, but it would essentially involve abandoning 3 to a large extent. Not very palatable.
I'm sure Python has many years to go though, so I wouldn't worry about writing new code for the moment. Keep an eye on how things develop and think about jumping to another language if no-one sorts out this mess.
I personally won't be moving till GAE, Azure, Amazon, PyPy, PyInstaller, and all Linux distros make the jump. Which at this rate appears to be never.
I'm going to do exactly what you're suggesting, and move off of Python entirely at some point. I'm truly amazed that GVR is dancing with death to kill Python over unicode and cruft. I'm hoping Python (2) becomes the community version and 3 remains the experimental branch.
* PyPy has a 3.x branch, which is apparently nearly complete
* Major distros, Ubuntu and Fedora, are also moving; Debian is also discussing it
Python 2 was released Oct. 2000 and so will have a 20-year lifetime now. http://en.wikipedia.org/wiki/Python_(programming_language)#H...
Ruby 1.8, which was retired last year, had 10 years of life: https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...
Obviously, version numbers don't mean the same thing...and Ruby 1.8.x to Ruby 1.9.x (or even 2.x) seems less of a jump than 2.x to 3.x.
The lambdas stayed, fortunately, but, unfortunately, I'm still convinced the whole project was a bad idea. The cosmetic changes which make Python 3 incompatible with Python 2.7 are just not worth the trouble of breaking the compatibility. Has anybody ever tried to estimate the man-hours needed to port the myriads of great Python 2.7 libs to Python 3 and weight it against the advantages of subtle language improvements? I don't think so. Plus, the big Python's problems like GIL are still there in Python 3...
If it was up to me I would drop Python 3 and focus the development effort of the community on improving PyPy and porting libraries to it.
I don't think it's entirely fair to call people who don't upgrade lazy or scared. However, it's really not that hard at all these days. Most packages are ported, and there are many success stories who have documented all the hard bits.
Who knows where 3.x will be in 6 years, but now a huge number of people will continue to develop in the 2.x series with no worries. Six years feels like a long time when you're at the beginning of them. By the end, maybe it will be easier to just tweak the Python 2.x codebase than switch everything to 3.x.
I'd never heard of Guile until you mentioned it. I looks like Scheme. If moving to a lisp-like language, Clojure, which you mention, would be a better choice. It's backers claim they'll be there for the long-term, and it has innovative concurrency constructs.
As for Groovy, it appears to be dying. Oracle went to a lot of trouble to create Nashorn, a zippy Javascript bundled with Java 8, and you can bet they'll be promoting it heavily in the "scripting Java" space to dislodge Groovy. Grails is losing adoption bigtime, getting replaced by Node.js, Play!, Django, and even Rails. When Gradle upgrades to version 2, they'll likely bundle some other JVM languages for their API, e.g. Nashorn.
No, what it is is "legacy Python 2.7 gets 5 more years where bugfixes that we expect certain major users of Python -- notably RedHat, which has 2.x bundled into releases that have long support terms -- to submit may be published to the world as bugfix (2.7.x) releases".
The mainstream of Python development has been 3.x for years, and that line will continue to keep evolving.
I know it's in SCL, but that lacks convenience for a lot of users.
https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
I contribute back to the community and I take the time to make sure my open source code works with both Python 2 and Python 3, but I will not drink the kool-aid. Not even for upvotes on HN ;-)
Slashdot has always highly valued humor. "+5 Funny" is a highly sought after moderation. So, perhaps in reaction, HN usually downvotes attempts at humor.
Neither approach is "better". It's just how the respective communities have evolved.