by michaelty on 12/7/11, 7:16 AM with 118 comments
by wladimir on 12/7/11, 11:23 AM
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...
by dmbaggett on 12/7/11, 1:33 PM
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 (http://pypi.python.org) lists 18 thousand 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.
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).
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.
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.)
by arethuza on 12/7/11, 9:06 AM
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?
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.
by jnoller on 12/7/11, 3:39 PM
As well as some other discussion here: https://plus.google.com/115662513673837016240/posts/9dLUJxg8...
by cageface on 12/7/11, 9:28 AM
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.
by yason on 12/7/11, 10:57 AM
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.
by zephyrfalcon on 12/7/11, 11:20 AM
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?
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.)
by nicpottier on 12/7/11, 9:19 AM
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.
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.
by plq on 12/7/11, 9:28 PM
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.
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.
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.
by pitiburi on 12/7/11, 8:52 AM
by viraptor on 12/7/11, 12:40 PM
> 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.
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?
by zbowling on 12/7/11, 9:01 AM
by perfunctory on 12/7/11, 9:30 AM
Since when correctness is not much?
by swdunlop on 12/7/11, 9:16 AM
by dcolish on 12/7/11, 4:18 PM
by kbd on 12/7/11, 9:32 AM
by dpkendal on 12/7/11, 12:51 PM
by DrCatbox on 12/7/11, 11:38 AM
The `estr` suggestion is quite welcome.
by perfunctory on 12/7/11, 9:18 AM
What is he talking about?
by ricardobeat on 12/7/11, 10:49 AM