Thoughts on Python 3

"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.<p>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.<p>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...<p>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...

Key line from the article: "Python 3 [...] changed just too much that it broke all our code and not nearly enough that it would warrant upgrading immediately."<p>To my thinking, Python, Ruby, and Perl make people productive primarily because of the availability of tons of high-quality packages that "just work". The Python Package Index (<a href="http://pypi.python.org" rel="nofollow">http://pypi.python.org</a>) lists <i>18 thousand</i> packages now. Many are very high quality and require essentially no "impedance matching" to use with Python 2.7 except "import package". If there's a genuine issue with a package, you can usually use a several-line monkey-patch and leave the package source completely untouched. Beauty.<p>Put simply: there's no way for a language design to make writing code easier than not writing code. IMO, this is why, despite the warts, these languages are winning. JavaScript doesn't have a standardized module/import system, so its packages are fragmented across a dozen frameworks. But this may change if the world settles on "one framework to rule them all" (or maybe two: jQuery for UI and node.js server side).<p>But Python 3 breaks many of the available Python 2.X packages, and in exchange for improvements that in most cases seem more like tweaks than major design fixes. Things that should be fixed in both branches (e.g., OpenSSL cert validation support) are now relegated to ad hoc patches to Python 2.X, because all the development effort is going into the 3.X series now.<p>Finally, the biggest improvement to Python IMO hasn't come from the core team at all: it's the absolutely brilliant work being done by the PyPy team. I would love to see "Python 4" merge some of the ideas from the 3.X branch in a fully compatible way with Python 2, and move the standard implementation to PyPY. Among many other benefits, this would allow the Python community to start seriously exploring adding static type-checking facilities to the language, which would make it far more suitable for larger projects. (I'm not saying make Python into Java, but it would be nice to be able to declare types as one can in modern Lisp implementations, and have the compiler both check correctness and optimize using such hints.)

"The multimethod based design of the language"<p>I've only just started looking at Python, but I wasn't aware that it has true CLOS-style multimethods (or multiple dispatch). I know that there are ways you can add multiple dispatch to Python - but is it really accurate to say that the entire language has a design that is based on multiple dispatch?<p>Note that I'd be rather pleased to find that multimethods are an integral part of Python - they were one of my favourite features of CLOS and I still miss them.

An excellent Python-Ideas post from Nick Coghlan on things we can tweak: <a href="http://mail.python.org/pipermail/python-ideas/2011-December/012993.html" rel="nofollow">http://mail.python.org/pipermail/python-ideas/2011-December/...</a><p>As well as some other discussion here: <a href="https://plus.google.com/115662513673837016240/posts/9dLUJxg8MPi" rel="nofollow">https://plus.google.com/115662513673837016240/posts/9dLUJxg8...</a>

<i>In fact if you go back in time and look at some of the first versions of Python it's a very, very ugly language and it does not come as a surprise that not too many people took notice of Python in the early days.</i><p>This is why I've always found it difficult to love Python. It just didn't seem to me that Guido was familiar enough with previous language designs or had a sufficiently refined sense of language esthetics to be a world-class PL designer. Over time the community has built Python into an extremely practical and useful tool, but I don't think I'll ever derive the same sense of pleasure from writing Python code that I do from languages with a stronger unifying concept like Ruby or Lisp or even OCaml.

I thought Python 3 was already D.O.A. I haven't seen anybody using it nor have I seen any compelling reason to start using it myself, or any reason at all to even keep it on my radar.<p>When v3 was announced, IIRC even the Python folks themselves actually suggested that people just continue with v2.x until later when v3 becomes mainstream and it never did. In fact, I was surprised to see negative criticism about Python 3. It seems to me that nobody has been using Python 3, and therefore not complaining about it either.

"In fact if you go back in time and look at some of the first versions of Python it's a very, very ugly language and it does not come as a surprise that not too many people took notice of Python in the early days."<p>I don't know... Python in the early 90s looked pretty much the same as it does now. Unless you mean that some features (or lack of them) required inelegant workarounds?<p>I think most machines were just not powerful enough yet in the 90s to make Python a viable solution for many problems. As computers got faster, that became less of an issue. Also, there was already a scripting language with a large following back then (Perl, naturally). Whether it was "ugly" probably had little to do with it. (Quite the contrary in fact, I recall that Python was often perceived as clean, elegant, concise and very readable.)

I'm actually pretty new to Python, using it daily for the past few years, but I do have to say I have a real uneasy feeling about Py3.<p>Adoption seems very slow from the various libraries, and without those people just won't move over. And if that's the case, then the language will stagnate, along with the myriad of great libraries that make it so excellent.<p>Python 2.x suits me just fine right now, it is a pragmatic language that lets me get things done quickly and predictably. But I would be lying if I didn't admit to gazing over Ruby's way now and then and thinking that the grass sure looks green over there.

Yes, porting to Python 3 is more cumbersome than it should be. Yes, some of the decisions (like crippling the byte types, or implicitly changing behavior based on environment variables) turn out to be bad decisions, but it still sounds like there's already some work towards fixing these. As more and more people gets to work with Python 3, that seems normal to me. As we know, "There are only two kinds of programming languages: those people always bitch about and those nobody uses." It seems to me that Python 3 has started to get its healthy dose of bashing, and that's a good thing.<p>As for my anectodal experience with 2to3: I've recently been working on porting rpclib to Python 3. After skimming the diffs it produced for a simple `2to3 src/rpclib` call, I chose to ignore most of the transformations it applies.<p>Replacing commas in except statements by the "as" keyword or adding parentheses where missing work just fine. But wrapping every call to dict.keys() inside a list() call? That's bold.<p>Once 2to3 is tamed[1], I think the code it generates can be maintained. Certainly beats having to get the current exception from sys.exc_info.<p>[1]: <a href="https://github.com/plq/rpclib/blob/master/2to3.sh" rel="nofollow">https://github.com/plq/rpclib/blob/master/2to3.sh</a>

Are you upvoting it because you agree with the rant, because you think it's time for a new debate over Python 2.8, because you think Python is losing space and turning into the future Pascal, because you hate 2to3, just because you think is nice to have some news about Python... It would be very interesting if some of you elaborate a little bit on what parts of this article you agree with.

Could someone explain this part?<p>&#62; Now this all would not be a problem if the bytestring type would still exist on Python 3, but it does not. It was replaced by the byte type which does not behave like a string.<p>I was under impression that bytes is just an array of bytes and provides pretty much what `str` provided. What big thing is missing from that interface?

I agree on the `estr' idea. I agree that it "punishes you" when you want to try and deal with byte strings. It really gets in the way with handling decoding and encoding of email.

"Python 3 ... does not offer much besides being more “correct”.<p>Since when correctness is not much?

Python 3 has one really significant problem for me -- many of my dependencies don't support Python 3 well or at all. That keeps me and my own modules locked in Python 2. Python used to be the language that bragged about coming with "batteries included", but it is slowly becoming the language that requires new batteries.

For me, the strongest point is about which version of Python everyone uses at work. When you have many commercial users its really difficult to get everyone to move. Python3 is not currently a target for my code at work because just writing the features is a full-time job. The difficulties in porting would not currently be worth the effort and I would have an extremely hard time justifying the ports business value.

What are the downsides of Ruby's alternate approach of having strings be bytes that carry an encoding object around?

Might Perl 6 suffer the same problems? Or will it be saved by virtue of its compatibility mode for Perl 5 code?

It is very difficult for a developer to support two code-bases, for the "same" language.<p>The `estr` suggestion is quite welcome.

"The multimethod based design of the language"<p>What is he talking about?

It strikes me that a developer working on the server side doesn't have at least an idea of what POSIX is.