James Bennett: “Let’s talk about Python 3.0”
James Bennett has posted a very informative defense of Python 3, in reaction to my more negative article.
I learned things from it, as from many of the comments on my post. I even agree with most of what he says, but it hasn’t really changed my opinion, because it seems like we’re not talking about the same things.
From the standpoint of writing Python code, Python 3 sounds great. It’s so nice not to have to deal with crufty APIs that don’t make sense anymore, or half-baked mechanisms like the original string class.
But from the standpoint of using Python libraries, I still think this is terrible. Any time I want to use a library I’ll have to check whether it works with the version of Python I’m on. I may find that a library I use, and need updates to, will no longer support Python 2.x going forward. And the porting and branch-maintenance process will definitely take time out of library developers’ schedules, slowing down other work.
(Since James had several great quotes in his article, here’s one making my point: In Elbonia, cars have always driven on the left side of the road. Finally, the government decides that it’s time to harmonize this with the country’s neighbors, and announces that Elbonia will change to the more standard right-side driving. But they’re going to phase it in: next Monday, trucks will switch to driving on the right, and the Monday after that, the cars will switch. Rim-shot! The weakness of this analogy is that the sensible choice for Elbonia—making everyone switch at once—doesn’t exist for something as distributed and anarchic as a programming-language community.)
For me, the second issue predominates. I’m more of a library-user than a hardcore Python coder. In fact, on balance, I like the core Python language less than Ruby. What won me over were the libraries: there are a lot of really well-designed, well-documented, highly modular libraries out there that I’ve really enjoyed using. (Genshi, to name just one, is the best templating engine I’ve ever used.)
So my perspective of the Python 3 release is that it heralds a difficult period, where library development and maintenance may slow, and grazing the Python ecosystem will become more difficult. Hopefully this won’t last too long. But the worst-case scenario is that this forking process may discourage enough software developers to reduce the popularity of Python in the long term. That’s bad not because popularity is important in itself, but because a vibrant community is important for maintaining forward progress, and because popularity brings useful things like books and tools.
December 6th, 2008 at 2:20 PM
I think it’s important to distinguish between two types of Python libraries: included and external. (I’m not saying you don’t know the difference, because you clearly do, but people newer to Python (especially those who use an installation done and maintained by someone else) may not be as clear on it.)
Included libraries will work in Python 3. (If not, that’s a huge bug.) For many tasks, the “batteries included” model is completely sufficient. This is one of the things that moved me off of Perl; navigating through the tangled web of CPAN dependencies just to get functionality that’s already in Python’s equivalent included libraries is wasted effort. (Yes, some libraries are removed in Python 3. Even though I’ve used some of them in my own code in the past, I have no complaints about the choices made.)
Libraries and frameworks that aren’t included will require some porting, and your concern that the time and effort involved will slow down library writers is a valid one. However, I think that the improvements in Python 3 will tend to limit the impact of that.
Your distinction between making life easier for those “writing Python code” while making it more difficult for those “using Python libraries” doesn’t take into account that Python libraries are created by people who are, after all, writing Python code.
None of us really know what the payback period will be, when the effort saved by no longer having to deal with Python 2’s warts exceeds that caused by the porting and transition effort from 2 to 3. My belief is that the latter is significantly smaller than you think it will be, and James’s is that the former is greater than you think it will be. If he and I are both right, the payback period could be quite short.
December 6th, 2008 at 3:30 PM
The thing that’s bugging me the most is simply the mindset that Python 3.0 must begin widespread use immediately or else it’ll represent some sort of problem with the migration process. The plan, as I’ve always understood it, is that 2.x and 3.x will be developed side-by-side for the next few years, and that libraries and frameworks are expected to migrate as and when they can, so that for at least two or three years 2.x will remain the dominant version in use.
And that seems like it’s the thing most likely to work; in a couple years, 2.6 or 2.7 will probably be the baseline “oldest Python shipping” in then-current OS distributions, so the recommendation that Python software move to a 2.6+ requirement and then use the much simpler upgrade path and automated tools to maintain and eventually migrate to 3.0+ will coincide nicely with the point, about two years out, when many major projects are talking about being ready to do this.
The biggest problem I can see for Python itself I can see right now, honestly, is simply that the advertising of Python 3.0 will lead newcomers into that “use it now” mindset (and already has in a couple places I’ve seen) and then lead them away disappointed; people who already know/use Python meanwhile, have a pretty smooth and gradual path toward 3.0.
December 6th, 2008 at 3:39 PM
Also, much as I hate to make the analogy to enterprise-land, I think it’s worth pointing out that this isn’t too different in nature from, say, Microsoft rolling a major rev of, or introducing major new components for, an ecosystem like .NET; people who don’t upgrade will get left behind on the new stuff, of course, but the upgrade itself will take place over a period of at least a couple years and everybody knows that going in. In fact, MS somehow manages to maintain a huge market share in the enterprise space despite doing this depressingly often.
Java’s another story because of their obsession with bytecode compatibility (see: “but Mom, why can’t we have real runtime generic types?”), but even there you get occasional massive revs of major frameworks/libraries which send everybody into a gradual upgrade cycle.
So if those folks can pull it off despite being actively hated by a lot of their customers and users, imagine what Python — which is generally liked by people who use it — can do ;)
December 7th, 2008 at 12:13 PM
I’m curious: the python community as a whole sees these changes as needed. Looking through the PEPs, the community seems to have put a lot of thought into the transition roadmap. If this isn’t the right way to do this, how would you do it?
December 7th, 2008 at 12:30 PM
Well, my problem is:
Since Python 3K is breaking backwards compatibility anyways.
Why keep *so much* language crap?
It was time to fix the syntax (get rid of this underscore nonsense), add some nice things as real closures, etc…
Instead we just get a fix for Unicode (ok, this is big, but almost all modern languages have this by now (Ruby 2, Groovy, the .NET scripting languages, Perl), it’s not like it would be a huge differentiator in the future) and some restructuring of the libraries…
December 7th, 2008 at 5:58 PM
What would you consider a “real closure”?
December 8th, 2008 at 5:21 AM
“Any time I want to use a library I’ll have to check whether it works with the version of Python I’m on. “
Yes, this is correct. For any python version. Obvously, for Python 3, it will take much longer before most libraries are available, and for the nearest 1-2 years, if you wnat to use Python 3 you will have to make more checks to see if the libraries are available or not before the project starts. If you don’t want to do that, stay with Python 2 for the time being.
I can’t shake the feeling that you are basically upset with Python 3 because you can’t use it NOW, IMMEDIATELY, because the libraries aren’t ready. That somehow you are miffed that you can’t use the latest (and greatest) version of Python because its incompatibiliets means it will take a while for libraries to catch up.
This is true, and understandable, but you have to also remember that the version hadn’t been as great if it was compatible.
The alternative would have been to introduce incompatibilities step by step, in a series of new releases. But that would just prolong the pain, so I’m not sure that is a good idea.
December 8th, 2008 at 5:25 AM
“Why keep *so much* language crap?”
I suspect we are in the realm of personal tastes here. I don’t think it keeps very much language crap. The only thing I don’t like in python 3 is that there *still* is no “Until” statement, for what I find dogmatic reasons. And I really don’t like comprehensions, although admittedly I use them all the time, so I’m a hypocrite on that part.
Other than that, it is pretty damn close to perfection, and if I was asked to design my perfect language, it would more or less be python 3.
December 8th, 2008 at 12:54 PM
On popularity: Keep in mind that this update is an improvement in nearly every respect to new users. I don’t even know Python, but I’m thrilled about the update because it’ll make Python so much easier and funner to learn and use when I get around to it. My respect for the developers and designers of the language has also increased immensely. I predict that Python will gain more users than it’ll lose with this update.
As an outsider, of course, I’m predisposed to these opinions.
December 8th, 2008 at 1:24 PM
Kelsey,
Well… yes and no. Entirely too much attention is being focused upon 3.0.
The big news in the Python world is really 2.6. And that is what new users should target. New users targeting 3.0 in the next year or so are in for a disappointment. The comprehensive library support will just not be there for them. And top level projects, like web frameworks, are planning on taking their time… maybe one or two years… to transition. A lot of projects want to maintain 2.3 and 2.4 compatibility a while longer, and 2.3 to 3.x is just a bit of a stretch.
Some of the “old hands” with large code-bases which are their responsibility are panicking. But they shouldn’t be. 2.x will be around, and even dominant, for a long while.
The 3.0 release represents something new appearing on the horizon. And that’s all. Pick up a book on 2.x for now; 3.x is really *not* that different, unless you already have a zillion lines of code that you feel that you have to convert right now for some reason.
December 8th, 2008 at 11:23 PM
I suspect foljs is complaining about the fact that you can’t alter bindings within the enclosed scope. To which I usually reply that Python’s closures are simply on par with Haskell’s ;)
(since in a strict single-assignment language like Haskell you can’t rebind any variable once you’ve assigned something to it, the analogy holds up; also, I find it curious that people who complain about Python lacking “real closures” never extend their complaint to single-assignment languages, but that’s a story for another day…)
December 9th, 2008 at 7:15 AM
””“
I suspect foljs is complaining about the fact that you can’t alter bindings within the enclosed scope.
“”“
But doesn’t the “nonlocal” statement in 3.0 allow just that?
http://docs.python.org/dev/3.0/reference/simple_stmts.html#nonlocal
December 13th, 2008 at 12:00 PM
I’ve blogged my own response here: http://mithrandi.vox.com/library/post/more-on-python-3.html
June 26th, 2009 at 7:01 AM
I maintain a few, quite small, libraries for Python (including the never-quite-dead gdmodule, which I took over with Richard’s blessing some years back). Many people have asked me when I’ll have 3.0 versions of the various libraries.
At this rate, never.
I have no incentive to do it. Perhaps I’m a strange old fogie, but I found the *language* nearly perfect back around 2.2… I never use list comprehensions in my code (I find them hard to read, so I don’t write them), nor do I use iterators or any other of the new syntax. Certainly, the semantics were impure, but they were *simple*, and I’m a bear of little brain. I far prefer a language I can hold entirely within my head to one I have to strain to read. If I were the other way around, I’d write Perl.
I do understand the motivations for the changes in 3.0, though I disagree with some of them; but what I have never understood is the farkling of the language, adding semantics borrowed from elsewhere to do things we can *already do just fine without them.*
(A “farkle” is a shiny bit you add to a motorcycle, sports car, etc. A luggage rack or a spoiler, for instance. Things not really needed, but which are “cool” to have.)
This isn’t just my natural reactionism. I truly believe that a simpler language breaks in simpler ways, just as any simpler system tends to break in simpler ways, so that the programmer can better understand why things go wrong (and more importantly, can more easily write error-free code the first time, an experience I never had before Python).