[wladimir]

"JavaScript is becoming more and more an ubiquitous scripting language that challenges Python"... The Python dev team cannot change these conditions; even if they came up with the perfect programming language tomorrow.

Python3 has some nice features and some that could have been better designed, but personally I don't think it's as bad as this author makes it to be. It's pretty much a logical progression of the 2.x series. Python 3 is being adopted, slowly. I still think it's simply a matter of time, as Linux distributions have plans to move on. No one expected it to go quick.

And I like that Python 3 makes Unicode versus Bytes explicit. There's working with sequences of symbols (for humans) and working with bytes (for machines). I regularly hoped this would be done when working with binary data and making hw interfaces in Python, as there is a lot of confusion regarding bytes/unicode in Python 2 also in libraries...

It was interesting to read some discussion and arguments for/against 3.0, but it could have done with a little less "Python is now doomed" attitude...

[mcdonc]

Well, the author has direct experience porting and maintaining (very popular, well-written, well-tested) Python libraries, so I think it bears more weight than the platitudes I hear from "the other side" of "it will all work out in the end, it's just a matter of time." I think the latter line of reasoning is going to fail without any specifics of how it's really meant to "all work out" if issues like the ones he's given examples of in the blog post aren't treated seriously (particularly the straddling-2-and-3-issues).

[zzzeek]

2to3 isn't perfect but I've made it work for SQLAlchemy and Mako - the Mako port was very easy. SQLAlchemy was trickier, largely because we still support all the way back to Python 2.4 (we're moving to 2.5 for 0.8).

When I wrote Alembic just recently, I ran 2to3 on it and it literally needed two "file()" calls to be changed to "open()" and that's it.

The contradiction in Armin's post is that he starts off with "we don't like Python because its perfect, we like it because it always does a pretty good job, etc. etc.". Aside from Armin's very specific issues with codecs (I've never used codecs that way) and with the filesystem (OK, he's convinced me work is needed there), I don't quite see how 2to3 is any different than "not perfect, but does the job at the end of the day".

Also, we really shouldn't be fixating on 2to3 very much - it is already deprecated. We should be thinking/worrying very, very, much about 3to2. Since we really should be shooting to have our source in all Python 3 within a couple more years.

[cdavid]

It may just be anecdotal at this point, but several highprofiles libraries have given up on 2to3 entirely and use the 2/3 common codebase approach: Jinja, django, ply. For a library, that's the approach that I find more practical.

I have a hard time seeing how one can use 2to3 on an everyday basis: it makes testing, distribution, etc... that much more painful because it is so slow (2to3 takes as much time as compiling all the C code from numpy, for example). It also removes one of the big plus of a language like python (modify code - see the result right away).

[mcdonc]

Amen, 2to3 in practice for anything but the smallest library is effectively unusable due to speed. Even if it weren't, I'm not much of a fan of maintaining generated code. That's an imposition I'm not really willing to put up with.

[zzzeek]

Using a Jenkins server with continuous integration makes Py3K testing pretty painless.

I really don't want projects to go back to maintaining two source trees, that was a disaster.

[llambda]

Just to further this sentiment, and perhaps even more worrisome, is how easily a language, even one as well established as Python, might fall out of favor. The fact that JavaScript usage is becoming ubiquitous as a scripting language was an example mitsuhiko was using of the challenges Python faces. Sure, the Python team can't stop that from happening, but they can stop pretending Python 3 is going to work just as soon as everyone gets on board with it. Hint: developers will adopt it when there are good reasons to use it and here the argument is that doing things more correctly (and consequently making life harder) is not a good enough reason when it comes to real world applications (Jinja2, Werkzeug, Flask, etc)

[jerf]

My objection to the idea that JS will so easily replace Python is that if you apply the same degree of analysis to JS that is causing you to reject Python, JS fares far worse. At least Python addresses the encoding issue, JS strings are far stupider, more dangerous, and require you to do a lot more of the paperwork if you can't assume an external environment that takes care of it for you (the browser, in this case). The next generation of JS fares somewhat better, if it is implemented according to the spec (and there quite a gulf betwixt a spec and an implementation), but when will you start being able to use that?

Try implementing even a medium-sized project in both Python and JS and tell me JS is a serious replacement, let alone for the large ones.

[DrCatbox]

Armin mentioned JS as an example of a language that could come and be favorable to developers contra Python.

Like clojure, or something else. Indeed, as a newcomer to Python I wanted to pick up python 3 from the start, but went back to python 2 becuase of poor library support.

If in the future people still decide to go with what works, they might as well go with a completley different language, that just works, not becuase it is the correct way.

[DasIch]

I doubt JS will ever replace Python and I doubt that is what Armin believes. That doesn't mean it cannot hurt Python significantly in terms of popularity and market share.

[jerf]

If JS gets to improve in the future, so does Python. Again, apply the same standards in both cases, which is my real point. Ranting about "accounting only the positives of one alternative and only the negatives of the other" is a bit of a hobby of mine. You can make anything look good or bad that way, but that appearance has no relationship to truth. You can't make good decisions that way, but people do it surprisingly often.

Also, encoding was one example. I could rant for hours about the ways in which Python is more suitable than JS(-of-today) for medium-or-greater sized projects.

[wladimir]

I am certainly not denying that there are issues or saying that his issues don't need to be addressed.

However I'm a big proponent of 'breaking with the past' once in a while, to fix issues that have snuck into the language/library/system, and to clean up the cruft. Yes it will bring some frustrating porting, but the end result will be a cleaner more focused language.

[mcdonc]

Your original post (and to an extent your reply above) was a bit dismissive, I think. Dismissiveness is not really a unique sentiment here; I see a lot of posts along the lines of "well yes he's complaining but it's a break with the past and its for the better, it's just a matter of time, and it will all work out in the end, yada yada"..

My point is that for this to actually be true (as opposed to just being wishful thinking, which there's a lot of right now), people are going to have to not only port their libraries but they will also need to maintain the resulting code. If the library is at all popular already, the resulting code will, for some open-ended period of time (perhaps "forever") need to work on both Python 2 and Python 3. And right now, though producing a port isn't monstrously hard, maintaining the resulting code across the 2/3 straddle is just no fun. The code looks bad, it's harder to read, it's harder to maintain, it's just less fun overall. Basically, maintaining a Python 3 port just takes some of the fun and aesthetic out of maintaining an open source library. It's an imposition to those folks who want their code to be popular, forward-compatible, and beautiful due to the need to straddle.

IMO, I'm not sure that a Python 2.8 helps much here, but a more backwards compatible Python 3.3 would. For example: match py3 bytes behavior with py2 string behavior, add u'' literals back in, maybe readd iteritems/iterkeys/itervalues on dict as aliases so we can use a common API for dicts, add the print keyword back in maybe, and other minor things that are really easy to do and don't have much defensibility other than "it's cleaner to not have to have bw compat here".

[wladimir]

Yes, a backward compatibility mode that could re-add those things would be nice (which could be enabled by adding a pragma "from __past__ import old_unicode_literals", for example). It would allow for a more gradual transition.

[mcdonc]

The pragma wouldn't really work. It'd have to work in all old versions of Python to make any sense, and it doesn't. For unicode literals in particular, it should just be true in Python 3.3+ that u'' = '' out of the box.

[cdavid]

Breaking stuff is worthwhile if it brings other things in exchange. Cleaner is almost never a good enough reason in my experience. New features is what makes people willing to upgrade. People will evaluate whether porting is worth the pain over this feature vs effort line. Armin is not the only one who wonders whether it really is worths it.

[wladimir]

But as more and more new features are being added to 3.x and not to 2.x (and assuming 3.x won't break compatibility with itself), won't there automatically be a point in which the features are worth the pain?

Even if not, the python devs are not trying to define this point for anyone, you can stay with 2.7 the rest of your life if you want to. I don't think a "2.x will no longer be maintained even for bugfixes" date has been established.

[cdavid]

There may be a point at which the features may worth it, I don't see why it should be automatic.

Python 2.x is not going away, but staying at 2.7 is not a long term solution either.

[exDM69]

It's also worth mentioning that Python ships with a nice "batteries included" type setup, where installing the basic CPython interpreter and the bundled libraries give you a quite nice collection of tools for common computing tasks (e.g. making HTTP requests).

In contrast, JavaScript does not have a "standard" implementation and doesn't ship with any libraries. Sure, there's Node.js and probably others too.

Once you have a serious project, where you have dependencies and build systems and source control, it's not a very big issue to get install a few libs. But for small projects, Python's batteries come in handy. And some of those small projects turn into big projects.

What comes to Python 2 vs. Python 3, I feel it's a "can't make an omelette without breaking eggs" kind of issue. Unfortunately many people are running business critical applications with Python 2 and are not willing to put in the effort to migrate their code to Python 3. This "don't fix it if it ain't broken" attitude has slowed down Python 3 adoption.

[klodolph]

I'm not sure that Python 3 adoption is "slow", per se. We're about halfway through the original adoption timeline.

http://sayspy.blogspot.com/2011/01/my-semi-regular-reminder-...

[joeyespo]

I didn't get the "Python is doomed" attitude from it. To me, it's more of a rant that maintaining code that works on both 2.x and 3.x is far from optimal, and that we can and should fix this.

I think he's right in that there needs to be less of a gap, possibly with a Python 2.8. Migrating to 3 isn't the problem, it's maintaining the versions until 3 becomes dominant and 2.x support can be dropped. The Python core team is essentially deferring the difficulty of compatibility to library maintainers. And since Python 3 is essentially a new language, why not just use a py2js if/when it emerges? It'd be just as difficult. And with the additional benefit of entering a more mainstream community. So yes, let's lessen the gap.

I also agree with you in that Python 3 just needs time. And once 2.x is no longer supported, let's also remember this lesson: don't make such big leaps in language evolution.

[e1ven]

The thing is, it's not even a BIG leap, just an invasive one.

This isn't all that similiar to perl5->perl6, which is a big leap.. The biggest problem is that they changed the default string type.