13 ms·

Thoughts on Python 3

302 points by michaelty 15y ago

pitiburi 15y ago
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.
- pyre 15y ago
  Not everyone up-votes because they agree with something. It's perfectly reasonable to up-vote something with the hopes that it hits the front page because you feel it will spawn an interesting discussion that you want to read and/or participate in.
  - pitiburi 15y ago
    Exactly, that is why, when i saw it with more than 20 votes but not a single comment that i dared to ask, honestly, why were they upvoting; I wanted to know the reasons. As you say, it can be for many different reasons, and I was interested in what the community thought about this. Sadly, that meant I could be misunderstood, and in fact I was downvoted for just asking, in the first comment on the new, to please know the REASONS the others were upvoting.
- swdunlop 15y ago
  I upvoted, because I thought about this very issue yesterday -- my primary project is a very large Python2 project that started after the declaration of 2.7.x as the end of the line. All of our dependencies were Python2, and many of them were too exotic or niche to have Python3 competitors. I feel that my position is actually a majority in the Python community -- language users who are stuck with the branch that is considered unfashionable by the core developers and adding more resistance against migration to Python3.
  - eliben 15y ago
    The Python core developers are not against you. Your case is perfectly valid and understood. The core developers do, however, try to prepare the ground that will make it possible even for projects like yours to eventually make the move. It is hoped that in some time most popular libraries will have Python 3 versions, and many Linux distributions will come with Python 3 pre-installed (Ubuntu is making good steps in this direction). Eventually, a time will come when it will make sense for you to make the switch. We just hope it won't be too long. All along, Python 2.7 is going to be maintained and bugs are going to be fixed. It is perfectly understood that the 2.x branch is currently by far the more used and deployed, and there's no plans to abandon it in terms of support. It just won't get new features.
zbowling 15y ago
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.
arethuza 15y ago
"The multimethod based design of the language" 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.
- swdunlop 15y ago
  I had a similar response, reading the article. Cue Inigo Montoya voice: "You keep using that word. I do not think it means what you think it means." http://www.youtube.com/watch?v=G2y8Sx4B2Sk http://www.youtube.com/watch?v=G2y8Sx4B2Sk
  - perfunctory 15y ago
    Bravo!
- berntb 15y ago
  Well, since this is about people not using Python 3 yet... It might amuse you to know that Perl 6, which isn't used either, has multi methods. :-) Edit: Dynamic dispatch otoh is in most (all?) scripting languages.
  - draegtun 15y ago
    Also Perl5 has multimethods via a Moose extension: https://metacpan.org/module/MooseX::MultiMethods https://metacpan.org/module/MooseX::MultiMethods
    - berntb 15y ago
      OK, thanks. I must add, risking down votes in this thread, that it is fun to see Python people argue the practicality of Python 2 over the idealism/correctness of Python 3. It is very similar to when Perl people argue that CPAN (better OO with Moose, better infrastructure for modules, etc) outweigh the emphasis on simple syntax in Python 2... :-)
swdunlop 15y ago
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.
- briancurtin 15y ago
  I'm also not sure your battery analogy works. The batteries that came with Python 2 (the standard library) are still charged up in Python 3. Third-party projects not porting certainly does affect you and others, but it's not the same thing.
perfunctory 15y ago
"The multimethod based design of the language" What is he talking about?
- mr1900 15y ago
  http://www.artima.com/weblogs/viewpost.jsp?thread=101605 http://www.artima.com/weblogs/viewpost.jsp?thread=101605 Not part of the language as far as I can see, more a way how you do this in python
- sirclueless 15y ago
  In a comment here on HN. the author clarified. What he means is that a whole bunch of builtin functions operate by calling methods on the objects they are passed. int(n) --> n.__int__() format(x, spec) --> x.__format__(spec)
  - perfunctory 15y ago
    It's not multimethods. It's just calling methods on the objects you are passed.
nicpottier 15y ago
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. 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.
- sigzero 15y ago
  Slow?! Thank God it was! Guido laid out a 5 year adoption timeline and things are moving along nicely being that we are only half way through it.
- briancurtin 15y ago
  > Adoption seems very slow from the various libraries, and without those people just won't move over. It started slow like we expected, but I think it's acceleration lately has outpaced what a lot of people thought would happen. The number of Python 3 packages on PyPI is steadily rising [0], the number of Python 3 installers downloaded from python.org is rising with each version [1], and the number of projects announcing Python 3 support in places like reddit.com/r/Python is rising every day. [0] http://dev.pocoo.org/~gbrandl/py3 http://dev.pocoo.org/~gbrandl/py3 [1] http://i.imgur.com/SLFDL.png http://i.imgur.com/SLFDL.png - monthly download numbers for Windows installers for all downloaded versions over the last year (it's a rough draft, I just threw the download numbers in Excel quickly one day).
cageface 15y ago
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. 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.
- dalke 15y ago
  I don't need to go back in time as I remember the 1990s. Even in 1995, Python was one of the top choices for high-level "scripting" or embedded languages. Perl was the hot language, and the other main choice was Tcl. I used all three non non-trivial projects, and liked Python the best. It was better at handling complex data structures than the other two. Tcl was an easier language for my target audience (scientist/non-professional programmers) and it was easier to embed and extend Tcl, but Python's module and object system made up for it. By the late 1990s, others in my field were already shipping Python-based applications, using Python bindings to Motif. IMO, people didn't take notice of Python because of the "strange indentation", because high-level languages are seen as being too slow for real work, and because people coming from a statically compiled language often want the assurance that compile-time type checking gives.
  - cageface 15y ago
    I started using Python in 1997 and found it profoundly mind-expanding since my previous experience with languages was limited to C/C++ and Pascal. But over the years I learned other languages and came to see missed opportunities and outright mistakes in the original design that I don't think a more experienced student of programming language design would have made. Many of the original mistakes have now been corrected but the churn in the language this has required means that it no longer "fits in my head" the way Ruby or C do.
- 15y ago
perfunctory 15y ago
"Python 3 ... does not offer much besides being more “correct”. Since when correctness is not much?
- fastviper 15y ago
  The context was XHTML. It was more correct but it was wrong (now dead) path. XHTML created only problems, but was "more correct" To be precise, XHTML promised that pages render faster, which turned out to be browsers fault, not markup. PyPy solves "render fast" problem for python2. What problem Python3 does solve? Unicode? No...
  - ricardobeat 15y ago
    XHTML was poised to offer much more than "correctedness". Reliable validation, custom DTDs, extensions, better interoperability. It just wasn't meant for the general web, where you have a massive number of non-technical authors. I don't think this comparison has any place in this discussion.
    - masklinn 15y ago
      > XHTML was poised to offer "supposed" would be a better fit than "poised". > much more than "correctedness" Not really > Reliable validation, custom DTDs correctness. > extensions Really debatable, xhtml only added "extensions" in the "XML dialects, RDF!!!" sense, in the effective sense HTML is extended all the time. > better interoperability At the cost of interop with the real world. And that better interop was restricted to markup (an issue being much better solved through HTML5 as browsers are moving towards spec-compliant HTML5 parsers), it left the "new" interop issues (CSS, JS, DOM, ...) in place. And XHTML offered this better interop by... mandating source correctness... > It just wasn't meant for the general web, where you have a massive number of non-technical authors. Which, interestingly, is also an issue with Python: it's used a lot in scientific fields and as an extension language (though less so than it used to be), which I'd guess would qualify as "non-technical authors" as they're not computer technicians.
    - dextorious 15y ago
kbd 15y ago
What are the downsides of Ruby's alternate approach of having strings be bytes that carry an encoding object around?
- grandinj 15y ago
  Makes some string operations more expensive because of the potential of having to convert between representations. So you have the choice of converting at source, and paying the price there, or converting during processing and paying the price there.
  - Someone 15y ago
    Lazy evaluation, however, has the benefit that, at least in theory, if conversion turns out to be unnecessary, one can skip conversion, and never pay the prize of conversion. One could have an abstract 'String' type with concrete subclasses (ANSIString, UTF8String, UTF16String, EBCDICString, etc) Assuming that any to-be-handled character strings can be round-tripped through UTF-8 (and that probably is a workable assumption), any function working with strings could initially be implemented as: - convert input strings to some encoding that is known to be able to encode all strings (UTF8 or UTF16 are obvious candidates) - do its work on the converted strings - return strings in any format it finds most suitable Profiling, one would soon discover that certain operations (for example, computing the length of a string) can be sped up by working on the native formats. One then could provide specific implementations for the functions with the largest memory/time overhead. The end result _could_ be that one can write, say, a grep that can work with EBCDIC, UTF8 or ISO8859-1, without ever converting strings internally. For systems working with lots of text, that could decrease memory usage significantly. Among the disadvantages of such an approach are: - supporting multiple encodings efficiently will take significant time that, perhaps, is better spent elsewhere. - the risk of obscure bugs increases ('string concatenation does not quite work if string a is EBCDIC, and string b is ISO8859-7, and a ends with rare character #x; somehow, the first character of b looses its diacritics in the result') - a program/library that has that support will be larger. If a program works with multiple encodings internally, its working set will be larger. - depending on the environment, the work (CPU time and/or programmer time) needed to call the 'correct for the character encoding' variant of a function can be too large (in particular, for functions that take multiple strings, it may be hard to choose the 'best' encoding to work with; if one takes function chains into account, the problem gets harder) - it would not make text handling any easier, as programmers would, forever, have to keep specifying the encodings for the texts they read from, and write to, files and the network. [That last one probably is not that significant, as I doubt we will get at the ideal world where all text is Unicode soon (and even there, one still has to choose between UTF8 and UTF16, at the least)] I am not aware of any system that has attempted to take this approach, but would like to be educated on them.
ricardobeat 15y ago
It strikes me that a developer working on the server side doesn't have at least an idea of what POSIX is.
- masklinn 15y ago
  You misread what he wrote. He knows what POSIX is in absolute, the question was what "POSIX" is as a locale. It's in the previous sentence: > I had the situation that when I logged into my remote server the locale was set to the string “POSIX”.
  - ricardobeat 15y ago
    Ugh. That's what I get for skimming. Sorry.
- godDLL 15y ago
  I work both sides, and I don't know what constitutes a POSIX encoding too.
yason 15y ago
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. 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.
- mathnode 15y ago
  Blender is using Python 3. I'll go and sit back down in my corner.
- baq 15y ago
  when python 2 showed up, people kept using 1.5.2 for _years_.
- briancurtin 15y ago
  If it was dead on arrival, it has risen from the grave quite nicely. I previously linked to two sources showing it has pretty good signs of life: PyPI packages and download numbers (posted here: http://news.ycombinator.com/item?id=3323908 http://news.ycombinator.com/item?id=3323908). When it was announced, people did suggest everyone continue on with 2.x, but not just until everyone waits for it to be mainstream (that clearly wouldn't work). No one expected users to drop everything and port right away. As your dependencies come up to speed with 3, try your project with them. Create an experimental branch. Do something to keep up. You don't need to halt your own progress for it, but you shouldn't sit on your hands. I've been using Python 3 at work for around 2 years now, writing test frameworks and tools in a C++ environment (working on a historical tick database). While a lot of the web people are stuck on 2, and that has been changing for a while and it's only getting better there, a lot of other areas have been available to and have been using Python 3.
- sp332 15y ago
  There's a 5-year roadmap, and we're about halfway through it. Many of the most popular libs are already available in Py3. For example Django just released a version supporting it. https://news.ycombinator.com/item?id=3305021 https://news.ycombinator.com/item?id=3305021
zephyrfalcon 15y ago
"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 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.)
- chalst 15y ago
  No GC, coupled with Guido's ignorant comments about how superior refcounts were. Wacky three namespace scoping. Back in those days, Python seemed cleaner than it was.
  - kzrdude 15y ago
    In a way that's still true. I'm thinking of `nonlocal` and attribute lookup which is all too complicated.
    - DrCatbox 15y ago
      And the GIL, in a world of multi-core processors with each capable of several threads... a single process is meh.
wladimir 15y ago
"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 15y ago
  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).
  - wladimir 15y ago
    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.
    - cdavid 15y ago
      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.
DrCatbox 15y ago
It is very difficult for a developer to support two code-bases, for the "same" language. The `estr` suggestion is quite welcome.
viraptor 15y ago
Could someone explain this part? > 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?
- mcdonc 15y ago
  http://docs.python.org/release/3.2.2/library/stdtypes.html#bytes-and-byte-array-methods http://docs.python.org/release/3.2.2/library/stdtypes.html#b... And this annoying feature: http://docs.python.org/dev/howto/pyporting.html#indexing-bytes-objects http://docs.python.org/dev/howto/pyporting.html#indexing-byt...
dpkendal 15y ago
Might Perl 6 suffer the same problems? Or will it be saved by virtue of its compatibility mode for Perl 5 code?
- iso8859-1 15y ago
  Funny how people claim Py3k was DOA. I don't know anyone who uses Perl 6 for anything serious. I'd bet that there are 100 times as many Python 3 programmers as there are Perl 6 programmers. I think Perl 6 still has a chance, though. No reason to dismiss it just because it's developing slowly. The compatibility mode doesn't do Perl 6 much good, if you ask me. There are already too many ways to write Perl, if you ask a Python programmer. It's like writing C in C++.
  - chromatic 15y ago
    Python 3 has been available and usable for quite some time. Not so Perl 6. However, CPAN compatibility would be hugely important to a usable Perl 6, by simple fact that no other language has the breadth and quality and availability of libraries to rival the CPAN.
- chromatic 15y ago
  Perl 5 (or, more accurately, CPAN) compatibility mode is only really interesting in two cases: when converting a project piecemeal from Perl 5 to Perl 6, and in the time between when Perl 6 gets generally usable and when it gets sufficient library support with native Perl 6 code. All of this depends on Perl 6 being generally usable and having a working Perl 5 compatibility mode.
- kamaal 15y ago
  Perl 6, is a major incompatible release. Its like compressing years of deprecation cycles in one major release. Larry wall realized long back that a few problems with Perl 5 can be fixed with incremental releases. I think there is CPAN compatibility mode, and Perl 5 programs are expected to run on Perl 6 compilers. Also Perl 6 is a total redesign but preserving the 'perl spirit' and its original design principles. OTOH, Python is taking the path of incrementally correcting its problems at the expense of breaking compatibility as and when needed. The problem is every time you break backwards compatibility, you forcing an upgrade timeline on users and during that you are allowing rival languages and communities to flourish. If people are using Python because it just 'works', then in its absence they will use something else too if it 'works'. Me personally if I knew that a particular tool is going to continuously break my code base every now and then. I would avoid it all costs.
dmbaggett 15y ago
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." 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 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.)
- civilian 15y ago
  Yes! This is great. I also haven't switched to Python3 because there aren't any "killer features". 2.7 works fine for me, and it often feels that the reason for switching to python3 is mildly religious.
- Fluxx 15y ago
  Rubinious (Ruby implementation) did something like this with their 2.0 release that supports MRI (CRuby) version 1.8.7 and 1.9.2 syntax.
jnoller 15y ago
An excellent Python-Ideas post from Nick Coghlan on things we can tweak: http://mail.python.org/pipermail/python-ideas/2011-December/012993.html http://mail.python.org/pipermail/python-ideas/2011-December/... As well as some other discussion here: https://plus.google.com/115662513673837016240/posts/9dLUJxg8MPi https://plus.google.com/115662513673837016240/posts/9dLUJxg8...
dcolish 15y ago
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.
plq 15y ago
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. 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. [1]: https://github.com/plq/rpclib/blob/master/2to3.sh https://github.com/plq/rpclib/blob/master/2to3.sh
- wahnfrieden 15y ago
  Maybe it needs an interactive mode?

302 points by michaelty 15y ago

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.

pyre 15y ago
Not everyone up-votes because they agree with something. It's perfectly reasonable to up-vote something with the hopes that it hits the front page because you feel it will spawn an interesting discussion that you want to read and/or participate in.
- pitiburi 15y ago
  Exactly, that is why, when i saw it with more than 20 votes but not a single comment that i dared to ask, honestly, why were they upvoting; I wanted to know the reasons. As you say, it can be for many different reasons, and I was interested in what the community thought about this. Sadly, that meant I could be misunderstood, and in fact I was downvoted for just asking, in the first comment on the new, to please know the REASONS the others were upvoting.
swdunlop 15y ago
I upvoted, because I thought about this very issue yesterday -- my primary project is a very large Python2 project that started after the declaration of 2.7.x as the end of the line. All of our dependencies were Python2, and many of them were too exotic or niche to have Python3 competitors. I feel that my position is actually a majority in the Python community -- language users who are stuck with the branch that is considered unfashionable by the core developers and adding more resistance against migration to Python3.
- eliben 15y ago
  The Python core developers are not against you. Your case is perfectly valid and understood. The core developers do, however, try to prepare the ground that will make it possible even for projects like yours to eventually make the move. It is hoped that in some time most popular libraries will have Python 3 versions, and many Linux distributions will come with Python 3 pre-installed (Ubuntu is making good steps in this direction). Eventually, a time will come when it will make sense for you to make the switch. We just hope it won't be too long. All along, Python 2.7 is going to be maintained and bugs are going to be fixed. It is perfectly understood that the 2.x branch is currently by far the more used and deployed, and there's no plans to abandon it in terms of support. It just won't get new features.

zbowling 15y ago

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.

arethuza 15y ago

"The multimethod based design of the language" 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.

swdunlop 15y ago
I had a similar response, reading the article. Cue Inigo Montoya voice: "You keep using that word. I do not think it means what you think it means." http://www.youtube.com/watch?v=G2y8Sx4B2Sk http://www.youtube.com/watch?v=G2y8Sx4B2Sk
- perfunctory 15y ago
  Bravo!
berntb 15y ago
Well, since this is about people not using Python 3 yet... It might amuse you to know that Perl 6, which isn't used either, has multi methods. :-) Edit: Dynamic dispatch otoh is in most (all?) scripting languages.
- draegtun 15y ago
  Also Perl5 has multimethods via a Moose extension: https://metacpan.org/module/MooseX::MultiMethods https://metacpan.org/module/MooseX::MultiMethods
  - berntb 15y ago
    OK, thanks. I must add, risking down votes in this thread, that it is fun to see Python people argue the practicality of Python 2 over the idealism/correctness of Python 3. It is very similar to when Perl people argue that CPAN (better OO with Moose, better infrastructure for modules, etc) outweigh the emphasis on simple syntax in Python 2... :-)

swdunlop 15y ago

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.

briancurtin 15y ago
I'm also not sure your battery analogy works. The batteries that came with Python 2 (the standard library) are still charged up in Python 3. Third-party projects not porting certainly does affect you and others, but it's not the same thing.

perfunctory 15y ago

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

mr1900 15y ago
http://www.artima.com/weblogs/viewpost.jsp?thread=101605 http://www.artima.com/weblogs/viewpost.jsp?thread=101605 Not part of the language as far as I can see, more a way how you do this in python
sirclueless 15y ago
In a comment here on HN. the author clarified. What he means is that a whole bunch of builtin functions operate by calling methods on the objects they are passed. int(n) --> n.__int__() format(x, spec) --> x.__format__(spec)
- perfunctory 15y ago
  It's not multimethods. It's just calling methods on the objects you are passed.

nicpottier 15y ago

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

sigzero 15y ago
Slow?! Thank God it was! Guido laid out a 5 year adoption timeline and things are moving along nicely being that we are only half way through it.
briancurtin 15y ago
> Adoption seems very slow from the various libraries, and without those people just won't move over. It started slow like we expected, but I think it's acceleration lately has outpaced what a lot of people thought would happen. The number of Python 3 packages on PyPI is steadily rising [0], the number of Python 3 installers downloaded from python.org is rising with each version [1], and the number of projects announcing Python 3 support in places like reddit.com/r/Python is rising every day. [0] http://dev.pocoo.org/~gbrandl/py3 http://dev.pocoo.org/~gbrandl/py3 [1] http://i.imgur.com/SLFDL.png http://i.imgur.com/SLFDL.png - monthly download numbers for Windows installers for all downloaded versions over the last year (it's a rough draft, I just threw the download numbers in Excel quickly one day).

cageface 15y ago

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

dalke 15y ago
I don't need to go back in time as I remember the 1990s. Even in 1995, Python was one of the top choices for high-level "scripting" or embedded languages. Perl was the hot language, and the other main choice was Tcl. I used all three non non-trivial projects, and liked Python the best. It was better at handling complex data structures than the other two. Tcl was an easier language for my target audience (scientist/non-professional programmers) and it was easier to embed and extend Tcl, but Python's module and object system made up for it. By the late 1990s, others in my field were already shipping Python-based applications, using Python bindings to Motif. IMO, people didn't take notice of Python because of the "strange indentation", because high-level languages are seen as being too slow for real work, and because people coming from a statically compiled language often want the assurance that compile-time type checking gives.
- cageface 15y ago
  I started using Python in 1997 and found it profoundly mind-expanding since my previous experience with languages was limited to C/C++ and Pascal. But over the years I learned other languages and came to see missed opportunities and outright mistakes in the original design that I don't think a more experienced student of programming language design would have made. Many of the original mistakes have now been corrected but the churn in the language this has required means that it no longer "fits in my head" the way Ruby or C do.
15y ago

perfunctory 15y ago

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

fastviper 15y ago
The context was XHTML. It was more correct but it was wrong (now dead) path. XHTML created only problems, but was "more correct" To be precise, XHTML promised that pages render faster, which turned out to be browsers fault, not markup. PyPy solves "render fast" problem for python2. What problem Python3 does solve? Unicode? No...
- ricardobeat 15y ago
  XHTML was poised to offer much more than "correctedness". Reliable validation, custom DTDs, extensions, better interoperability. It just wasn't meant for the general web, where you have a massive number of non-technical authors. I don't think this comparison has any place in this discussion.
  - masklinn 15y ago
    > XHTML was poised to offer "supposed" would be a better fit than "poised". > much more than "correctedness" Not really > Reliable validation, custom DTDs correctness. > extensions Really debatable, xhtml only added "extensions" in the "XML dialects, RDF!!!" sense, in the effective sense HTML is extended all the time. > better interoperability At the cost of interop with the real world. And that better interop was restricted to markup (an issue being much better solved through HTML5 as browsers are moving towards spec-compliant HTML5 parsers), it left the "new" interop issues (CSS, JS, DOM, ...) in place. And XHTML offered this better interop by... mandating source correctness... > It just wasn't meant for the general web, where you have a massive number of non-technical authors. Which, interestingly, is also an issue with Python: it's used a lot in scientific fields and as an extension language (though less so than it used to be), which I'd guess would qualify as "non-technical authors" as they're not computer technicians.
  - dextorious 15y ago

kbd 15y ago

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

grandinj 15y ago
Makes some string operations more expensive because of the potential of having to convert between representations. So you have the choice of converting at source, and paying the price there, or converting during processing and paying the price there.
- Someone 15y ago
  Lazy evaluation, however, has the benefit that, at least in theory, if conversion turns out to be unnecessary, one can skip conversion, and never pay the prize of conversion. One could have an abstract 'String' type with concrete subclasses (ANSIString, UTF8String, UTF16String, EBCDICString, etc) Assuming that any to-be-handled character strings can be round-tripped through UTF-8 (and that probably is a workable assumption), any function working with strings could initially be implemented as: - convert input strings to some encoding that is known to be able to encode all strings (UTF8 or UTF16 are obvious candidates) - do its work on the converted strings - return strings in any format it finds most suitable Profiling, one would soon discover that certain operations (for example, computing the length of a string) can be sped up by working on the native formats. One then could provide specific implementations for the functions with the largest memory/time overhead. The end result _could_ be that one can write, say, a grep that can work with EBCDIC, UTF8 or ISO8859-1, without ever converting strings internally. For systems working with lots of text, that could decrease memory usage significantly. Among the disadvantages of such an approach are: - supporting multiple encodings efficiently will take significant time that, perhaps, is better spent elsewhere. - the risk of obscure bugs increases ('string concatenation does not quite work if string a is EBCDIC, and string b is ISO8859-7, and a ends with rare character #x; somehow, the first character of b looses its diacritics in the result') - a program/library that has that support will be larger. If a program works with multiple encodings internally, its working set will be larger. - depending on the environment, the work (CPU time and/or programmer time) needed to call the 'correct for the character encoding' variant of a function can be too large (in particular, for functions that take multiple strings, it may be hard to choose the 'best' encoding to work with; if one takes function chains into account, the problem gets harder) - it would not make text handling any easier, as programmers would, forever, have to keep specifying the encodings for the texts they read from, and write to, files and the network. [That last one probably is not that significant, as I doubt we will get at the ideal world where all text is Unicode soon (and even there, one still has to choose between UTF8 and UTF16, at the least)] I am not aware of any system that has attempted to take this approach, but would like to be educated on them.

ricardobeat 15y ago

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

masklinn 15y ago
You misread what he wrote. He knows what POSIX is in absolute, the question was what "POSIX" is as a locale. It's in the previous sentence: > I had the situation that when I logged into my remote server the locale was set to the string “POSIX”.
- ricardobeat 15y ago
  Ugh. That's what I get for skimming. Sorry.
godDLL 15y ago
I work both sides, and I don't know what constitutes a POSIX encoding too.

yason 15y ago

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

mathnode 15y ago
Blender is using Python 3. I'll go and sit back down in my corner.
baq 15y ago
when python 2 showed up, people kept using 1.5.2 for _years_.
briancurtin 15y ago
If it was dead on arrival, it has risen from the grave quite nicely. I previously linked to two sources showing it has pretty good signs of life: PyPI packages and download numbers (posted here: http://news.ycombinator.com/item?id=3323908 http://news.ycombinator.com/item?id=3323908). When it was announced, people did suggest everyone continue on with 2.x, but not just until everyone waits for it to be mainstream (that clearly wouldn't work). No one expected users to drop everything and port right away. As your dependencies come up to speed with 3, try your project with them. Create an experimental branch. Do something to keep up. You don't need to halt your own progress for it, but you shouldn't sit on your hands. I've been using Python 3 at work for around 2 years now, writing test frameworks and tools in a C++ environment (working on a historical tick database). While a lot of the web people are stuck on 2, and that has been changing for a while and it's only getting better there, a lot of other areas have been available to and have been using Python 3.
sp332 15y ago
There's a 5-year roadmap, and we're about halfway through it. Many of the most popular libs are already available in Py3. For example Django just released a version supporting it. https://news.ycombinator.com/item?id=3305021 https://news.ycombinator.com/item?id=3305021

zephyrfalcon 15y ago

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

chalst 15y ago
No GC, coupled with Guido's ignorant comments about how superior refcounts were. Wacky three namespace scoping. Back in those days, Python seemed cleaner than it was.
- kzrdude 15y ago
  In a way that's still true. I'm thinking of `nonlocal` and attribute lookup which is all too complicated.
  - DrCatbox 15y ago
    And the GIL, in a world of multi-core processors with each capable of several threads... a single process is meh.

wladimir 15y ago

"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 15y ago
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).
- wladimir 15y ago
  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.
  - cdavid 15y ago
    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.

DrCatbox 15y ago

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

viraptor 15y ago

Could someone explain this part? > 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?

mcdonc 15y ago
http://docs.python.org/release/3.2.2/library/stdtypes.html#bytes-and-byte-array-methods http://docs.python.org/release/3.2.2/library/stdtypes.html#b... And this annoying feature: http://docs.python.org/dev/howto/pyporting.html#indexing-bytes-objects http://docs.python.org/dev/howto/pyporting.html#indexing-byt...

dpkendal 15y ago

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

iso8859-1 15y ago
Funny how people claim Py3k was DOA. I don't know anyone who uses Perl 6 for anything serious. I'd bet that there are 100 times as many Python 3 programmers as there are Perl 6 programmers. I think Perl 6 still has a chance, though. No reason to dismiss it just because it's developing slowly. The compatibility mode doesn't do Perl 6 much good, if you ask me. There are already too many ways to write Perl, if you ask a Python programmer. It's like writing C in C++.
- chromatic 15y ago
  Python 3 has been available and usable for quite some time. Not so Perl 6. However, CPAN compatibility would be hugely important to a usable Perl 6, by simple fact that no other language has the breadth and quality and availability of libraries to rival the CPAN.
chromatic 15y ago
Perl 5 (or, more accurately, CPAN) compatibility mode is only really interesting in two cases: when converting a project piecemeal from Perl 5 to Perl 6, and in the time between when Perl 6 gets generally usable and when it gets sufficient library support with native Perl 6 code. All of this depends on Perl 6 being generally usable and having a working Perl 5 compatibility mode.
kamaal 15y ago
Perl 6, is a major incompatible release. Its like compressing years of deprecation cycles in one major release. Larry wall realized long back that a few problems with Perl 5 can be fixed with incremental releases. I think there is CPAN compatibility mode, and Perl 5 programs are expected to run on Perl 6 compilers. Also Perl 6 is a total redesign but preserving the 'perl spirit' and its original design principles. OTOH, Python is taking the path of incrementally correcting its problems at the expense of breaking compatibility as and when needed. The problem is every time you break backwards compatibility, you forcing an upgrade timeline on users and during that you are allowing rival languages and communities to flourish. If people are using Python because it just 'works', then in its absence they will use something else too if it 'works'. Me personally if I knew that a particular tool is going to continuously break my code base every now and then. I would avoid it all costs.

dmbaggett 15y ago

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

civilian 15y ago
Yes! This is great. I also haven't switched to Python3 because there aren't any "killer features". 2.7 works fine for me, and it often feels that the reason for switching to python3 is mildly religious.
Fluxx 15y ago
Rubinious (Ruby implementation) did something like this with their 2.0 release that supports MRI (CRuby) version 1.8.7 and 1.9.2 syntax.

jnoller 15y ago

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

dcolish 15y ago

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.

plq 15y ago

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. 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. [1]: https://github.com/plq/rpclib/blob/master/2to3.sh https://github.com/plq/rpclib/blob/master/2to3.sh

wahnfrieden 15y ago
Maybe it needs an interactive mode?