[eesmith]

Covered in https://learnpythonthehardway.org/book/nopython3.html .

If I understand the trolling logic, "if it's impossible for Python 3 to support Python 2 then Python 3 cannot be Turing complete." This hinges on 'impossible' being used as a technical objection.

The argument should be that it's economically infeasible for Python 3 to support Python 2, not that it's technically impossible.

[joshuamorton]

Even then he's wrong. It's perfectly economically feasible to write a python2 interpreter in python3-the-language. Take an rpython based py2 interpreter and make sure the rpython code is py3 compatible.

What he suggests is that since the python3 interpreter cannot run python2 code, that somehow this implies that python3 the language is not turing complete. This makes about as much sense as saying that since gcc won't compile my Java code, C++ isn't turing complete. In fact it's the same statement.

And there are, in fact, valid reasons why the python3 interpreter cannot run both 2 and 3 code intertwined (mostly because things are ambiguous in such a situation. Does `{}.keys()` return a list or an iterator? How do you decide? Well you need to know if the code you're running is py2 or py3 in advance and you don't.

I include his original statement here: [1].

[1]: https://www.reddit.com/r/shittyprogramming/comments/5ejbr9/p...

[eesmith]

I made the statement about economically feasible, not Shaw. Based on many readings of the Python developer comments, there wasn't enough people time + money to make that happen for mainline Python, that is, CPython.

Your statement is perhaps true about Python-the-language. CPython has additional constraints, including specific details of reference counting and extension APIs, as well as the desires of the current developers. You'll note all the work that PyPy has had to do for that level of compatibility, and it's still not perfect.

My comment was with respect to "Shaw also declared". Shaw's posting is, in my reading, obvious mockery and not a declaration of a truly held belief.

I don't see how a flamebait posting in a Reddit group titled "shittyprogramming" means much about the contents of his book or the topic of this thread.

Isn't there something more substantial about his opinions to criticize?

[joshuamorton]

(his comment was quoted in shitty programming not originally made there. It was originally made in the blog post where NOTE I was trolling now appears, I just found the first quote in shitty programming).

My comment has nothing to do with cpython. Python2, the language and Python 3, the language, are ambiguous. The broader context for Shaw's comments were that the py3 interpreter should just transparently run py2 code. Without a flag, that's not possible. Not like hard, or a time investment, or something like that. But truly probably impossible. `print(b'b'=='b')` will give a different result in 2 vs 3. An interpreter can't transparently run both. It needs to know which is which.

As to your last question, not really. Very few of his opinions on py3 made any sense to people who were at all informed. The problem was, his audience is uninformed people.

[eesmith]

(I only have access to Reddit through a text browser, which makes it hard to figure out what's going on. I deliberately blocked Reddit at my firewall since I found the noise level entirely too high, and don't think this is an important enough topic to unblock.)

shrug I'm not here to really support or defend Shaw, only to say that kalimoxto's comment seems like a frivolous reason to disagree with Shaw's opinions on Python 2/3. Why not pick one of his more substantive statements?

What URL to you mean for the "blog post where NOTE I was trolling now appears"? https://learnpythonthehardway.org/book/nopython3.html ? The earliest archive.org entry for the page has the note:

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

Now, I happen to believe he's wrong - lack of staff and funding are perfectly reasonable justifications.

I listen to The Changelog podcast, and in episode #300 Shaw himself has argued that open source projects (including Python, though he didn't say that directly) are underfunded. "the strategy is if you keep the cost and the amount of money that these developers make down, then it’s easier to take their project and use it, and they can’t fight you back, they can’t sue you in court if you violate the GPL, all these things, and then you commoditize your complement, and off to the races".

As for Python 2/Python 3 co-existence, I'll note that Python/Tcl co-exist as part of the standard distribution. (Python calling Tcl for Tk calling back to Python.) I've had Python/R coexist. Shaw argues that the existence of something like .Net shows that general co-existence is possible.

I don't see him making the argument that it must be 'transparent'. But since I don't know the original source, I could have missed it.

FWIW, I considered writing a Python 2 tool to modify the AST and generate new code that would check for run-time behavior that was inconsistent with Python 3. For example, if x.values() where x is a dict was only used in an iter context, and x is never modified, then it doesn't need a list(x.values()) during the conversion.

In essence this would be a Python 3 implementation for Python 2, used to help identify problems that might come up in the 2/3 transition without jumping immediately to Python 3.

I couldn't get the business model to come anywhere near working. And since it's not hard for Python 3 code to create an AST for Python 2 and modify it, but no one has written a Python 2 in Python 3 implementation, even with the much greater demand, I again argue that it's an expensive project to do.

So anyway, I bit the bullet. Here are more substantive points:

> The end result of this defect is that most people will not bother switching to Python 3 as rewriting Python 2 code is the same switching costs as just using a totally different language completely.

This is not true. My switch from Python 2 to Python 2+3 took 2 months. It took several years to develop the application in the first place. The switching costs would have been far higher to switch to another language, even ignoring that I depend on third-party components which were already in Python 2+3 that I would need to replace.

> The strings in Python 3 are very difficult to use for beginners.

So far I've only taught 2 beginning Python courses for Python 3.6, vs about 20 for Python 2. I didn't notice much difference. Python 2 strings are also difficult. FWIW, I taught f-strings from the get-go, which worked for everyone. It's annoying that I have to also teach the two older forms. (Really, I point out they exist then ignore them.)

> The choice to not have Python 3 run legacy code will be the main reason it does not get adopted.

Since Python 3 is about par with Python 2 in use, Shaw's conclusion is wrong.

> "members of the Python project have actually told me this is impossible"

Names or citations/context would be nice. Shaw makes many statements concerning anonymous people. What did they mean by 'impossible' and did Shaw misunderstand them?

> There is no technical reason for the Python 3 version to differ from the behavior of the Python 2 version, they just decided that you should have to handle all the type problems related to Unicode and bytes with no help.

Python 2 didn't handle all the type problems either.

  >>> addstring("\xff", u"\u012c")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 2, in addstring
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal
  not in range(128)

while in Python 3:

  >>> addstring(b"\xff", u"\u012c")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 2, in addstring
  TypeError: can't concat bytes to str

> even the error message is macho and terse

Though the Python 3 error message in my example is easier to understand in this case than the Python 2 one.

Hmmm. Does the traceback let you know which expression caused the failure? I thought it was only to the line number of the expression/statement. That makes it difficult for anything to do better than simply report which variables were active in that line, like what the Django debugger does.

[Alex3917]

> If I understand the trolling logic

Zed trolls as a didactic technique. Don't pay attention to what he says, pay attention to what he's actually trying to teach you.

[viraptor]

This works if you have a small target group which understands it without explanation. Zed writes for the internet. That approach makes him a troll, not a clever teacher.