That "learn python the hard way" guy says don't use python 3. As someone who is at the "Hello World" stage, should I use 2 or 3?
I think in 2019 there is no question that you should be using python 3. Zed seems to be personally offended by both how the transition was handled and some of the design choices in python 3, but I think he is doing his readers a disservice if he is still recommending python 2 today.
They are wrong. There is no good reason to start with Python 2 for new projects. The reasons people stay on 2.x are institutional inertia and legacy code. A hello world program has none of these problems.
The work started around 2 years ago - https://zedshaw.com/2017/04/22/learn-more-python-rough-draft... .
Shaw doesn't "agree with the direction of Python 3", and regards it as "being a complete waste of human energy" - https://zedshaw.com/2017/08/26/what-if-it-worked/ . But that's different than saying that new projects, in 2019, should not start in Python 3.
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.
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...
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?
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.
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)
>>> 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
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.
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.
Beyond that, I personally don't find the arguments presented in versions of the book that recommend beginners learn Python 2 to be all that compelling. They read to me as one complaint about string handling that's wildly at odds with my own experience, nestled in a great big bowl of sour grapes about the fact that the breaking changes are happening in the first place.
The library support issue is a consideration, but depends heavily on what you want to do. My own sense has been that it's tools that are primarily used by devops and sysadmins that have the poorest Python 3 support, whereas the rest of the ecosystem is more-or-less 100% migrated at this point. Many have already started to discontinue Python 2 support. So, if you're saying that you're at the "Hello World" stage, I'm guessing that you'll hit a lot fewer speed bumps if you just start with Python 3 and don't look back.
His complaints are bizarre. He mostly claims that Python 3 sucks because he can't figure out how to convert his old Python 2 code to work on Python 3 easily so therefore a beginner couldn't possibly learn the language from scratch. But all of his examples are edge cases of him intentionally fighting against the changes in Python 3 by doing things that don't make any sense like trying to concatenate unicode strings with raw binary data. It's just the weirdest argument ever.
Python 3 makes almost everything slightly simpler and more logical - especially if you ever have to deal with unicode text. And since emojis are unicode and people love emojis, that means literally everyone.
Overall, he comes off to me like people who spend a lot of time ranting about USB-C ports when in reality USB-C is mostly great and honestly just isn't that big of a deal anyway. It's a strange hill to die on.
The only good historic argument for using Python 2 was that it used to be that some popular libraries weren't updated for Python 3 yet. But that hasn't been true for years. Nowadays you are more likely to run into libraries dropping Python 2 support than you are to find them not supporting Python 3. I can't think of a single remotely popular library that still doesn't support Python 3.
Both have been resolved.
Use Python 3
In fact, I would even say that the difference between Python 2 and Python 3 syntax is far less than the syntax difference between traditional javascript and the latest revisions to javascript (ES6+).