[iodbh]

Which turned into a big internet fight, and he changed his mind.

It's good to see people willing to change the way they do things, especially when that means publicly contradicting their former selves and with such an intense personality. It's oddly inspiring.

[jhbadger]

Also, when he wrote it was kind of true. A lot of things hadn't been ported to Python 3 yet and using it was asking for pain. Now finally we are in the opposite situation where many things are ending support for Python 2 and the easier route is Python 3.

[thehardsphere]

He wrote his rant a few months ago, which was well after every major library switched to Python 3.

Dunno if you mean his previous book or the rant where he said, among other things, that Python 3 wasn't turing complete.

[jhbadger]

He updated it a few months ago, but he's had versions of this for quite some time. Yes, maintaining it in late 2016 is somewhat stubborn, but it made a lot of sense in the early years of Python 3.

[thehardsphere]

I have a difficult time believing that we're talking about the same rant, because the one I'm talking about would not have made any sense even in the early years of Python 3.

Oh, I see it's been updated with a sober disclaimer now, where "In the previous version I trolled people" and "I even had a note after the gag saying it was a gag, but everyone is too stupid to read that note even when they do elaborate responses to my writing."

I read his writing very carefully. This note didn't exist.

[thehardsphere]

For those of you now breaking out the Internet Archive to prove the note existed

> "Yes, that is kind of funny way of saying that there's no reason why Python 2 and Python 3 can't coexist other than the Python project's incompetence and arrogance. Obviously it's theoretically possible to run Python 2 in Python 3, but until they do it then they have decided to say that Python 3 cannot run one other Turing complete language so logically Python 3 is not Turing complete."

Even though he says it's a "funny" way to say something, his explanation of said "joke" is not a correct description of what Turing completeness is. There is no "gag" here; Zed didn't understand it, and when people on the internet corrected him, he decided to play it off as a gag.

Edit: Just to make it explicit for those of you reading who don't get it, "Turing completeness" doesn't mean "I can run a program written in X in Y's runtime." It means that a language is capable of expressing all operations a Turing machine can do, which means that you can re-write a program in X to a program in Y if both X and Y are Turing complete. You can obviously re-write a Python 2 program to be a Python 3 program, so both of those languages are Turing complete.

The property he describes later, of the JVM and the CLR supporting multiple languages has absolutely nothing to do with Turing completeness. Lisp and Javascript are both Turing complete languages, but the fact that you can't run Lisp on Node.js doesn't mean you can't re-write a Lisp program in Javascript. The fact that he's equating being able to run many languages on a single runtime and Turing compleness means he doesn't understand what he's talking about.

[webmaven]

>> Obviously it's theoretically possible to run Python 2 in Python 3, but until they do it then they have decided to say that Python 3 cannot run one other Turing complete language so logically Python 3 is not Turing complete."

> "Turing completeness" doesn't mean "I can run a program written in X in Y's runtime."

That's not quite what he meant. He meant that Turing completeness of both languages implies that an interpreter for Python 2 can be written in Python 3,and that if the Python maintainers say it isn't possible, etc. etc.

Which is technically true, except that it is completely obvious that the performance of Python 2 under that arrangement would so totally suck that no sane developer would ever take that approach (and I can believe that the Python maintainers just said "that won't work" or some such), and that is what he apparently didn't understand (or is now claiming he pretended not to understand for comedic effect).

[lmkg]

> "Turing completeness" doesn't mean "I can run a program written in X in Y's runtime."

It's not the definition of Turing Complete, but it is a provable property of Turing-Completeness. If Y is Turing-Complete, then you can use Y to write an interpreter for X. Then the issue is reduced to arguing about what the word "in" means in the phrase "run Python 2 in Python 3."

[derekp7]

> but the fact that you can't run Lisp on Node.js

But you can write a Lisp interpreter in Node.js, because they are both Turing complete. In fact, I believe I've seen tutorials written up on how to write a Lisp in Javascript.

[eastWestMath]

In other words:

http://i.imgur.com/pLOrJ.jpg

[sfilipov]

Agreed, it's not a problem of theoretical possibility. It's just that the maintainers' time can be better spent improving Python 3 than maintaining a Python 2 compatible runtime.

[srssays]

> You can obviously re-write a Python 2 program to be a Python 3 program, so both of those languages are Turing complete.

This is true, but the converse isn't true. e.g. Python and brainfuck are both turing complete, but Python has interfaces around a hell of a lot more syscalls than Brainfuck which only has operations for reading and writing from stdio. You can't write a Python implementation in brainfuck, it is impossible.

[albedoa]

> I read his writing very carefully. This note didn't exist.

If only there were a machine with which we could go way back:

https://web.archive.org/web/20161123042252/https://learnpyth...

Yes, that is kind of funny way of saying that there's no reason why Python 2 and Python 3 can't coexist other than the Python project's incompetence and arrogance. Obviously it's theoretically possible to run Python 2 in Python 3, but until they do it then they have decided to say that Python 3 cannot run one other Turing complete language so logically Python 3 is not Turing complete. I should also mention that as stupid as that sounds, actual Python project developers have told me this, so it's their position that their own language is not Turing complete.

[joshuamorton]

If you check hacker news and reddit threads from the original posting, that note wasn't on the article when it was originally posted. It was only added later, but apparently still before anyone archived it.

Edit: I'm mistaken, however I'll say what I said then again:

The note does nothing to show that he actually understands the statements he's making. The note gets the definition of turing completeness wrong too.

[phaemon]

You didn't read it carefully enough. It did exist.

It read:

"Yes, that is kind of funny way of saying that there's no reason why Python 2 and Python 3 can't coexist other than the Python project's incompetence and arrogance. Obviously it's theoretically possible to run Python 2 in Python 3, but until they do it then they have decided to say that Python 3 cannot run one other Turing complete language so logically Python 3 is not Turing complete. I should also mention that as stupid as that sounds, actual Python project developers have told me this, so it's their position that their own language is not Turing complete."

See: http://web.archive.org/web/20161123042252/https://learnpytho...

[emondi]

That was sarcasm against the impossibility of running python 2 code in the python 3 interpreter.

[thehardsphere]

I'm sure that defense is just as valid as "we were hacked and someone wrote all of those dumb things we said in exactly our writing style."

[baldfat]

I think Zed was in the majority when it came to Py3. He kind of comes off as a jerk due to his personality, but I really like his approach and he always makes me think. I might not agree with him but he certainly is not boring. Looking at Pandas which is a R like library. Wes wrote his book in Py2 and did not have any desire for Py3.

I moved from Python mostly to using R, Racket and Haxe for my other side projects. This infighting just left a bad taste in my mouth and started seeing greener pastures, which for once in my life were in fact greener. I still love Python but I don't use it much due to community drama.

[kbd]

> Wes wrote his book in Py2 and did not have any desire for Py3

I find it hard to believe you're citing a book that was published in 2012[1], when it made sense to still target Python 2, as relevant to today's argument. The new version is updated for Python 3.5[2].

[1] http://shop.oreilly.com/product/0636920023784.do

[2] https://www.safaribooksonline.com/library/view/python-for-da...

[sigzero]

It's like there is no sense of time on the Internet! That was 4 years ago. People change their minds. That's a good thing.

I agree with you totally.

[baldfat]

I am totally confused. Zed Shaw wrote in 2010 how he didn't like Python 3 and his book wasn't going to show Python 3. Then he edited the note in November 2016 restating his position again.

Sometime between November 2016 to today he decided to release a Python 3 version.

I mention that the original idea that Python 3 was not a good practice in 2010 and was the majority view and again in 2012 a major library was released with Python 2 as its main target with the majority of the community was fine with the Python 2 focus.

Why am I making no sense time line?

I like Zed Shaw as a member of the Python community and I was defending his stance on sticking with Python 2 (I personal supported Python 3 since announcement)

So what is you agree and disagree with totally?????

[BuckRogers]

Don't blame the community for that. Blame Guido and the core development team. The community at-large weren't rallying for breaking changes to the language. GvR wanted that, it's "his" language afterall. Of course some of the community are more conservative and were willing to more quickly fall in line to goosestep with the core team on Python3. So the tension stems from the Python3 folks having extreme disdain for all the Python2 users and codebases.

I agree with you though, it's what got me looking towards other tech like Node, Go, Elixir. I can look past it all except for the fact they got 'unicode by default' wrong. They should simply do what Go does, everything is a bytestring with assumed encoding as UTF8. What they have today is ridiculous and needs changed before I could embrace Python3+.

[soperj]

There were definitely people wanting unicode support, which was the breaking feature.

They supported python 2 for years and year after the release of this, don't know how you can even mention the word goosestep in this context.

[BuckRogers]

I can't understand what's going on with the Python community for folks to even make statements like yours. It has to be an influx of new Python developers who started on 3.

Python2 has unicode support. Python2 already had (better) async IO with Gevent (Tornado is also there). There's just nothing there with Python3 except what I can only describe as propaganda from the Python Software Foundation that has led to outright ignorance with many users.

Some people wanted "unicode strings by default". Which Python3 does have, but they even got that wrong. The general consensus on how to handle this correctly is to make everything a bytestring and assume the encoding as being UTF8 by default. Then like Python2, it just works.

[deviscool]

Sorry, why you say python 2 asyncio is better? Python 3.5 - 3.6 new native! asyncio looks great https://maketips.net/tip/146/parallel-execution-of-asyncio-f...

[int_19h]

> The general consensus on how to handle this correctly is to make everything a bytestring and assume the encoding as being UTF8 by default.

Whose "general consensus"? It's certainly not the approach adopted by the vast majority of mainstream general-purpose programming languages out there.

[BuckRogers]

You mean most of the mainstream, genpurpose languages in usage today which were initially designed 20-50 years ago. And those which don't actively look for opportunities to shoot themselves in the face with sidestepping changes to break the language? Then no, not that consensus.

But if you were to find any sensible designer of new language with skyrocketing, runaway popularity- such as Rob Pike, they'll tell you differently. Or even Guido van Rossum, if he were to be honest with you. While Pike's colleagues at Bell Labs like Dennis Ritchie may not have designed C this way for obvious reasons, they did design Go that way.

[spangry]

You might find this worth a read: http://sircmpwn.github.io/2017/01/13/The-problem-with-Python...

[BuckRogers]

I normally wouldn't respond to any comments that are merely a link to someone elses thoughts without something original of your own. Because it means you likely don't know what you're talking about and merely attempting to speak through someone else because you think you agree. So I will respond not to your benefit but for anyone else who is new to Python and may come across this.

I've read that before and the author is ignorant. He's parroting GvR & the CPython core development team's line that unicode strings are codepoints. Sure, but he's arguing with himself and note the argument is Python2 vs 3. That narrow focus is what results in his tunnelvision. As a result of the argument as he frames it, Python3 is not better than Python2 in string handling, it's merely different. One favors POSIX (Linux), Python2. One favors the Windows way of doing things, Python3.

There is an outright better way to handle strings. It's what Google did with Go. How do we know it's better? Well, it is because it makes more sense on technical merits and members of the CPython core dev team have admitted that if Python3 were designed today they would go down this path. But during the initial Python3000 talks this option was not as obvious. Bad timing or poor implementation choices. Take your pick, given the runaway feature-soup that Python3 has become I'd assume both.

So like all tech, let Python3 live or die on its technical merits. That's exactly what the PSF has been afraid of, so we have the 2020 date which is nothing more than a political stunt among others. Python3 is merely different, it favors one usecase over another, but did not outright make Python better. To break a language for technical churn is and was a terrible idea.

[spangry]

You're right, I do lean towards agreeing with the author of the blog post. However, I wasn't (and am still not) in any way certain, and didn't want to be one of those asses you see on the internet who turn everything into a religious war. So I just put the information out there because I (in my ignorance) thought it was useful information from which intelligent people could draw their own conclusions.

Honestly, I don't care a great deal about string handling in Python and just wanted to inject (what I thought was) more information into the discussion. I'm kinda regretting that now. Lesson learned: steer clear and leave it to the experts.

I'm curious, how does Go handle strings?

[BuckRogers]

Well, I'm not an expert but in effort for full-disclosure Guido and the CPython core dev team aren't either. They hold a myriad of excuses for their decisions and they're all highly suspect from even a casual observer that doesn't just drink the koolaid. In the end, they'll just tell you they maintain CPython so only their opinion matters. Fair, but they're still wrong. Python3 is controversial for good reasons.[0] It's not lazy folks or whatever ad hominem is out there today. I couldn't tell your intentions given the lack of information included with your post.

Go handles strings by having strings be like Python3's byte-strings and unicode-strings as one type. This enables code to be written that generally doesn't force you to very often think about encodings, which you shouldn't have to as UTF8 is the one true encoding.[1] Or litter your code with encode/decode, or receive exceptions from strings (see Zed's post on some of that) where there wasn't previously. Python3 solved the unicode emojibake mixing unicode and bytes problems that some developers created for themselves in Python2, but did so by forcing the burden to every single Python3 developer, and breaking everyone's code while simultaneously refusing to engineer an interpreter that could run both CPython2/3 bytecode. Which is possible, the Hotspot JVM and .NET CLR prove it. Shifting additional burdens to the developer in situations where it's necessary, makes sense. It wasn't here because of both Python's general abstraction level, and Go showed it can be solved elegantly. Strings are just bytes and they're assumed to be UTF8 encoding. Everyone wins. Only Windows-specific implementations like the original .Net CLR shouldn't be UTF-8 by default, internal and external representation. Only a diehard Windows-centric person would disagree or someone with a legacy implementation (Java, C#, Python3 etc). The CPython3 maintainers fully admit they're leaning towards the Windows way of handling strings.

As you know, handling text/bytes is fairly critical and fundamental. For Python3 to get this wrong with such a late stage breaking change with no effort to make up for it with a unified bytecode VM is unfortunate. Add in the feature soup and the whole thing is a mess.

[0]http://learning-python.com/books/python-changes-2014-plus.ht...

[1]http://utf8everywhere.org/

[Analog24]

Pandas is a python library but it is based on the concept of a Data Frame from R.

[crncosta]

Yes, it is a good thing!! I am glad he turn back from his previous decision. His book is nice.