As this rebuttal points out, the original article basically finds two flaws in Python 3 and then tries to puff them up as much as possible. These two complaints are:<p>* Python 3 is not backwards-compatible with Python 2.<p>* Byte strings and character strings are different things so now I have to care about stuff.<p>Although I say that it's two things, it's really one thing since the main element of incompatibility is the byte string/character string issue, since it's that incompatibility that makes it hard to know what the right thing to do is.<p>Having had to deal with internationalization before, I can honestly say that there's only one way to handle it: convert all string data to your internal representation (be it UTF-8 (Rust), UTF-16 (Java), or UTF-32 (Python)) at the margin where you read/write it, and keep binary strictly separate from textual in terms of representation. This is what Python 3 does and what Python 2 doesn't do. I have seen some people argue that Python 2's model is better because it means that writing something like cat is harder, but that's optimizing for the wrong thing. I've seen a build system written in Python 2 break for the sole reason that I thought to write 一 in the commit message.<p>As for the complaint that it's taking 9 years for Python3 to slowly become the default instead of Python2, keep in mind that 15 years after the release of C99, gcc was still using C89 by default (gcc 5 skipped C99 and went straight to C11).
This is a great rebuttal against such an awful book for teaching.<p>Last year I recommended this book for a friend that was starting to learn to program. After a few weeks I was talking to him about lists, and he didn't understand what I was saying because it doesn't touch a <i>basic concept like a list</i> until Chapter 32! It takes literally two seconds to explain to a person what lists are, maybe a little longer for syntax. Given that he invites people to read other people's code early on (in one of the single digit lessons IIRC), this is a serious omission.<p>In addition to this, much of the attitude towards programming in the book isn't so much of "Woah! A new thing! It's so cool let's learn it" (i.e. energetically curious), but tends to rebel against new things in a "Well, I know it'll be hard and difficult..." way, which I honestly believe is damaging to new programmers. Programming is one of those disciplines where if you don't have a positive spirit towards both bugs and learning new things, you will get worn down over time. I think it's best to either already possess such an attitude or to show people documentation, etc. that helps them develop such an attitude when learning.<p>I ended up prodding my friend to pick up Lua. Partly because he was more interested in games development (and there is a great community for that around the Love2D engine), because it is a small enough language to learn and memorize in a week or two, and because I wanted to undo the damage that reading LPTHW had caused on his attitude towards programming.
Mr. Shaw's book used to be a decent starter reference. I liked his step by step short chapters, but there were some red flags. For example, he spent several early chapters on string formatters, which are neither terribly common nor useful for a beginner. Other key concepts like iteration were not adequately explained, or introduced far too late in the progression.<p>Besides the demagoguery, this new piece displays shocking ignorance of basic CS concepts. I will now actively warn my students against consulting his work.<p>Thanks to eeveee for a detailed rebuttal, which displays an appropriate amount of reprobation, given the original's caustic tone.<p>Python is an incredible community effort. It deserves support and constructive participation.
I certainly didn't get Zed's article, like maybe I'm not familiar with the superior toolings of other languages, but whenever I've used python2to3 I found it helpful enough to get real work done. For example, two years ago, I fell squarely in beginner segment skill wise, and I filed an issue with a repo owner to request to update to be python 3 compatible (an ORM for RethinkDB - <a href="https://github.com/linkyndy/remodel" rel="nofollow">https://github.com/linkyndy/remodel</a>). The obviously talented repo owner initially responded he feared it would be complex and take a long time. I then spent a weekend to learn the library, used 2to3 to get 95% there, fixed the remaining small issues, and updated the repo to be compatible with Python 3, passing all tests. Sometimes these python2 programmers just do not want to change.
Great point for point rebuttal. I was annoyed at the original article when it was circulated recently. As eevee points out, most of the original author's points are invalid or unimportant, and to me it seems that he is just mad he has to write another "learn Python" book for Python 3.<p>I'm a Python beginner and I recently wrote a few small tools in Python 3. They have a few functions, do network I/O, argparsing, connect to PostgreSQL, etc. It took me a few hours and it was fun.
It's human nature to resist change. Making a clean break and avoiding backwards compatibility was the smart move, it annoyed many, but I look around and see some languages truly suffering from such things years down the track.<p>Python3 is superior, its nothing but fandom when people say otherwise. Starting from scratch I'm yet to see any real benefit for 2, yet it still happens routinely due to the mindsets of some.
Maybe Curmudgeon Driven Development is a thing. I was totally surprised that by the end he hadn't advocated Perl 6. Like, "This is how it should be done: Parrot in Perl 6".<p>I was hoping out of this kerfluffle that some one would make Python3's TypeError show which variable was the byte string and the normal string. I haven't seen any people argue for improving the error reporting. It's that kind of thing that helps beginners when they start trying to do things with their current knowledge.
I'm amazed how people always list "three ways of formatting strings", when in fact there are four. :)<p>Admittedly, the fourth is not built-in, but it's part of the standard library: string.Template
for all his points about adoption of python 3, i think an interesting data point is that many of the OpenStack projects are actively converting (or already have converted) to python 3. that's no small amount of python.
<p><pre><code> # -*- coding: utf8 -*-
print "Hi, my name is Łukasz Langa."
print "Hi, my name is Łukasz Langa."[::-1]
</code></pre>
This is a bad example. Reversing Unicode strings isn't an operation that is often needed in practice, and it shouldn't be done codepoint-wise anyway, because some characters have to be represented with multiple codepoints:<p><pre><code> Python 3.5.2 (default, Nov 7 2016, 11:31:36)
[GCC 6.2.1 20160830] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 'x́q'[::-1]
'q́x'
</code></pre>
Doing it properly is bit of a grapheme clusterfuck: <<a href="http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries>" rel="nofollow">http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries...</a>.
It's really not surprising to me that the original link to Shaw's article is buried on HN.<p>This is exactly what he is talking about: it's not about right or wrong anymore, it's all about tribalism. I can remember when RoR was the newest, hip, thing in Silicon Valley. If you even mentioned something wrong with it on HN, you were silenced and downvoted.<p>There were real issues with RoR that needed to be addressed, but the community developers would rather spend time silencing opposing opinions that actually fixing the flaws in the language.<p>Where are these developers now? They all moved onto Javascript frameworks and node.js.<p>There are real issues with Python 3. The Python 3 faction of the community has basically told anyone that asks to fuck off and do things their way.<p>The responses here on HN and this 'rebuttal' have really just proven his point. I would have rather it proven him wrong.