And still not using python3.X …
I don't think it is useful for a beginner to start with python3.
Python3 simplifies many aspects of the language, for example handling of bytes and handling different encodings. In my day to day use I don't want to miss these features.
Many interesting features where added in 3, like yield from, more powerful generator syntax and the libraries multiprocessing and pathlib.
Even NumPy and SciPy work on Python 3 now, and it's not like there are massive differences between Py2 and Py3 anyway, so generally speaking it shouldn't be hard for a noob to revert to Py2 if it becomes inexplicably necessary.
It's time. All new code should be in Python 3.
It will happen someday, but not yet.
The majority of python code on my computer is now python 3.
I have a few smaller projects I have started since then - I used Python 3.
There are very few noticeable differences. Why would you not start with a more up to date version. Unless there are specific packages you need or expect to need that are not supported I would say Python 3 makes more sense.
In his explanation of classes he has several paragraphs about old-style vs. new-style classes, ending it with:
"Just completely ignore the idea of old style versus
new style classes and assume that Python always requires
(object) when you make a class. Save your brain power for
something important."
Another example is his advice, in exercise 11, to avoid the input() function because of its security problems. Python 3 doesn't have that function, so the beginner doesn't have to remember to avoid it.
And of course, there's Unicode, which this book seems to completely ignore. A beginner starting with Python 3 has to learn the "Unicode sandwich" approach[1], which applies very well to Python 2 code as well. But someone starting with Python 2 can easily be confused about the concept (because the language is confused) and will have a hard time getting things to work correctly. For example, the book recommends that people "from another country" set their source encoding to UTF-8 – good luck printing things on Windows.
[1] Obviously your experience may vary depending on which modules are considered essential for your work.
Also, all my Python sources are set to UTF-8 and I never had any problem in Windows. Notepad.exe gives you the encoding option when you save a file, and every sensible text editor/IDE gives you encoding and line feed options.
So what would be the problem with Zed's tip? Have you ever tried to run a Python script with special characters? The interpreter dies instantly with an encoding error. It's easier to set the encoding to UTF-8 and get the program running than parse the whole thing checking whether you used a special character in the comments -- which shouldn't affect program execution, but hey!. Also, this way you can write meaningful comments in your native language without worrying if it'll kill the interpreter right away.
For example, let's say our Other Country is a Western European country. The encoding for non-Unicode Win32 programs will be Windows-1251 (more or less ISO 8859-1) and the encoding for MS-DOS programs and the commandline will be codepage 850.
In this scenario, this Python 2 program (saved as UTF-8):
#-*- coding: utf-8 -*-
print "ångström"
To make it correct, you can apply the Unicode sandwich approach:
1) Know the input encoding and decode from that to Unicode.
2) Process the text as Unicode.
3) Know the output encoding and encode into that encoding on output.
In other words, making it a Unicode string will transform the text from whatever encoding you chose to write the file in to whatever encoding your terminal happens to use, so this program will always (if the system is correctly configured) print the right thing:
#-*- coding: utf-8 -*-
print u"ångström"
print("ångström")If anyone is best in the position to take up the bleeding edge with no thought to backwards compatibility, it's the people just starting out. They're the ones who, by definition, don't have legacy code to maintain.
True beginners don't need to use numpy and run a bunch of production-ready libraries. They first need to learn what libraries ARE and the basics of using them. Besides, numpy &c. can already run on Python3, how much further will they be along in 1-3 years? Most simple Python3 programs work fine in Python 2.7.9 with little wrangling, and it's not hard to keep two installs of Python.
"Learn Python" right now means "learn both", only many introductory tutorials will refuse to teach both. Instead they'll compound your frustration by making you learn the intricacies of Python 2's print statement instead of print().
The vast majority of code out there is in Py2, so if someone learns Py2 first, they can start coding and doing stuff right now. If they stumble onto a need for Py3 later, then they would have the skill to learn Py3 from the tutorial and other books.
If they learn Py3 first, then immediately they have to learn Py2 because there's simply too much code out there that uses it. This will frustrate beginners as the next thing they need to do after my book is start using Python to make things.
When the situation changes, and not just because the Python leaders say it does, then I'll update the book. Honestly though, I think Go, Rust, Nim, and Clojure have a better chance at widespread adoption than Python3 at this point.
Incidentally, the mistake that the Python3 project made was to not use a virtual machine that could run both 2 and 3 byte code. If I can run tons of languages on my CPU, the JVM, and the .NET CLR, then Python3 could have run both 2 and 3. I predict that to get people on the new version of Python they will have to make Python4 and have it run 2,3 and 4 seamlessly so that it won't matter how much code is out there in any version of the language.
Just my .02 on that topic.
I tried that for about a week before discovering that about 90% of the libraries that I wanted to play with, and 90% of the tutorials and StackOverflow answers that I found were 2.7-specific.