Not In Your Best Interests

The Python project's efforts to convince you to start with Python 3 are not in your best interest, but, rather, are only in the best interests of the Python project.

This should ultimately be the only reason you need to not start with Python 3. Ask yourself, why are they so keen on having you use a language that has only about 30% adoption, is constantly changing, and full of issues? The reason is getting beginners hooked on Python 3 means more adoption, which benefits Python 3. They don't care that you'll have problems, struggle too much, and potentially fail because of technical limitations in Python 3. They only care that you, a beginner, will amount to one more user. One more true believer.

I want you to just get started programming and that is all. I don't care what language you use, which is why I have a free book on Python and on Ruby. The language doesn't matter to me at all, and I'm not going to push a broken language on you. The Python project, however, has no problem pushing a broken language on you so that means you should avoid it until they fix it. Some people go so far as to ban my book because it does not support Python 3, even though my book is the most effective method for learning to code. The second someone starts banning books you know they don't care about anything but their own agendas.

Ultimately though, if Python 3 were good they wouldn't need to do any convincing to get you to use it. It would just naturally work for you and you wouldn't have any problems. Instead, there are serious issues with Python 3 for beginners, and rather than fix those issues the Python project uses propaganda, social pressure, and marketing to convince you to use it. In the world of technology using marketing and propaganda is immediately a sign that the technology is defective in some obvious way.

This use of social pressure and propaganda to convince you to use Python 3 despite its problems, in an attempt to benefit the Python project, is morally unconscionable to me.

Poor Design Decisions Prevent Adoption

The Python project decided to make it impossible to run legacy Python 2 code under Python 3. They even go so far as to claim this is "impossible" when basic computer science says this is very possible and done all the time. Given they controlled both language implementations and purposefully decided to prevent Python 3 from running legacy code, I have to conclude that Python 3 is defective on purpose. 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 means you are working with a purposefully broken platform when you use Python 3, and I personally can't condone teaching people to use something that is fundamentally broken.

Difficult To Use Strings

The strings in Python 3 are very difficult to use for beginners. In an attempt to make their strings more "international" they turned them into difficult to use types with poor error messages. Every time you attempt to deal with characters in your programs you'll have to understand the difference between byte sequences and Unicode strings. Don't know what that is? Exactly. The Python project took a language that is very forgiving to beginners and mostly "just works" and implemented strings that require you to constantly know what type of string they are. Worst of all, when you get an error with strings (which is very often) you get an error message that doesn't tell you what variable names you need to fix.

In addition to that you will have 3 different formatting options in Python 3.6. That means you'll have to learn to read and use multiple ways to format strings that are all very different. Not even I, an experienced professional programmer, can easily figure out these new formatting systems or keep up with their changing features.

Throw into that a proposal for yet another string type and you have a nightmare for anyone who's starting out in programming. The reason why I loved Python for beginners is it was easy to use. A total beginner could easily start making useful code right away. The Python 3 project has ruined that in their failed attempt to internationalize Python.

When you start out programming the first thing you work with is strings, and python made them far too difficult to use for even an experienced programmer like me to use. I mean, if I struggle to use Python's strings then you don't have a chance.

Core Libraries Not Updated

Many of the core libraries included with Python 3 have been rewritten to use Python 3, but have not been updated to use its features. How could they given Python 3's constant changing status and new features? In my own testing I've found that when a library could detect Unicode it fails to do so and returns raw byte arrays. What that means is you'll use a library, get what you think is a text string, and then have your code explode with a weird error message that has no variable names in it. This then is randomly distributed, with some libraries figuring out the Unicode status of data and others failing, and even some that fail or succeed within the same library.

Until there is a standard for what every library should return you cannot rely on Python 3's libraries to properly give you characters encoded. The solution is to create a "string" type that magically knows how to be Unicode or raw bytes, but the Python community is against anything they consider "magic" so they'd rather beat you over the head with their bad design and tell you it's a nice massage.

The Python 3 VM Is Poorly Designed

The choice to not have Python 3 run legacy code will be the main reason it does not get adopted. Here's the breakdown of my reasoning:

• Python 3 uses a Virtual Machine (VM) just like Python 2 did.
• The original design of Python 3 could have also run Python 2 in this same VM. They controlled both languages, and could make it work. They chose not to do this, and instead tell you to manually translate.
• F#/C# and JRuby/Java are good examples of doing this. The former, when you have control over both languages. The latter, when you don't.
• Successive versions of Java are another example of doing this, and may be closer to Python 2/3 integration.
• Choosing not to support both Python 2 and Python 3 in the same VM makes the transition cost off Python 2 much higher than it needs to be. Rather than support a smooth transition, the Python project instead asks you to manually convert code instead of simply supporting both languages.
• When asked why they don't run both, members of the Python project have actually told me this is impossible. This is a lie. It is not impossible, and in fact would have been the better design to help with migration.
• This poor design choice of Python 3 prevents easy migration, reduces adoption, and forces you to do their work for them. The difficulty in having to manually translate code simply because Python 3 refuses to support Python 2 by design means that there is a high probability it will not succeed.
• When I say "it will not succeed" people think, "compared to Python 2", when I really mean, compared to other languages.
• To me, I find it unconscionable to use other people's free labor to cover for a poor design decision. I doubt they'll fix this, but it's my evidence that says Python 3 will not see the necessary adoption to be successful.

Purposefully Crippled 2to3 Translator

I originally said this was 100% possible but honestly I should have said the 2to3 translator should have just not been necessary. I also think I was wrong in saying it was 100% possible. I think a better wording is, "If they designed Python 2 and 3 correctly the 2to3 translator would work perfectly."

I also feel this section just doesn't help explain why Python 3 isn't usable for beginners. The high switching cost of having to manually rewrite code is a valid concern. The lack of support for running Python 2 code is a valid friction on switching. Having a broken 2to3 translator though is just a symptom of the problem, not a cause.

This version will have this not but eventually I'll strip this down to the essentials and remove this pointless point I tried to make.

Statically Typed Strings

Python is a dynamically typed language. That means I do not have to know the type of variable to use it. As long as it behaves like another type, I am free to effectively pretend it is that other type. Whether that's a good computer science decision or not is pointless. Dynamic typing is what makes Python easy to use and one of the reasons I advocate it for beginners.

In Python 3, I cannot reliably use these function:

def addstring(a, b):
    return a + b

def catstring(a, b):
    return "{}{}".format(a, b)

If we have a string and a bytes type then when we call the first function we get an error, and the second we get a repr formatted byte string. I actually prefer the first response as it means I'm not randomly sprinkling b'blah' all over the place without knowing it.

Here's me trying to use these two functions in Python 3.5:

Python 3.5.1 (default, Sep 16 2016, 13:36:12)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def catstring(a, b):
...     return "{} {}".format(a,b)
...
>>> x = bytes("hello", 'utf-8')
>>> y = "hello"
>>> catstring(x, y)
"b'hello' hello"
>>>
>>> def addstring(a, b):
...     return a + b
...
>>> addstring(x, y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in addstring
TypeError: can't concat bytes to str
>>> ^D

By comparison here's the Python 2 version:

Python 2.7.11 (default, May 25 2016, 05:27:56)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def catstring(a, b):
...     return "{}{}".format(a,b)
...
>>> def addstring(a, b):
...     return a + b
...
>>> x = "hello"
>>> y = bytes("hello")
>>> catstring(x, y)
'hellohello'
>>> addstring(x, y)
'hellohello'
>>>

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. This a classic "Macho Code Guy" move and it has no place in a language for beginners. Difficult usability is not a marker of a better programming language, or better programmers. It is only a marker of arrogant people doing the implementation. However, when you point out that this is hard to use they try to claim it's good for you. It is not. It's simple blustering covering for a poor implementation.

A final note on this is even the error message is macho and terse:

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

If they're going to require beginners to struggle with the difference between bytes and Unicode the least they could do is tell people what variables are bytes and what variables are strings. They probably consider helpful error messages "magic" though so don't hold your breath they'll actually fix this one.

Dynamic and Static Mismatch

One fatal flaw of this decision to "static type" the strings is Python lacks the type safety gear to deal with it. Python is a dynamic language, and doesn't support type declarations on function arguments. It's also not statically compiled as strongly as it could be, so you can't find these kinds of type errors until you run the code. In the past this wasn't an issue because you'd write tests and the dynamic nature of Python meant things kept working as long as the method signature of types was the same.

Strings are also most frequently received from an external source, such as a network socket, file, or similar input. This means that Python 3's statically typed strings and lack of static type safety will cause Python 3 applications to crash more often and have more security problems when compared with Python 2.

Core Libraries Not Updated

There are several libraries that, despite knowing the encoding of data, fail to return proper strings. The worst offender seems to be any libraries dealing with the HTTP protocol, which does indicate the encoding of the underlying byte stream in many cases. In many cases the library uses the old API that relied on dynamically typed strings, but doesn't update to help with the returned values. It returns what you think is a "string" but is really bytes when the proper return should now most likely be the raw bytes plus any encoding information the library can figure out.

What's even more idiotic about this is, Python has a really good Chardet library for detecting the encoding of byte streams. If Python 3 is supposed to be "batteries included" then fast Chardet should be baked into the core of Python 3's strings making it cake to translate strings to bytes even if you don't know the underlying encoding. In fact, I'd like to see this:

x = bytes('hello', 'utf-8')
y = x.guess()

The point being that character encoding detection and negotiation is a solved problem. Other languages do it to varying degrees of success without the constant exceptions being thrown. Python 3 however has taken the stance that, since they think strings being unicode are "important", that means you must constantly be aware of them and constantly have to deal with them. To them, usability is counter to safety, when that's not true at all.

Too Many Formatting Options

Currently Python 3 supports the old style of formatting:

print "Howdy %s" % ('Zed')

The new .format() style:

print "Howdy {}".format('Zed')

And in Python 3.6 we will have a formatting style that's more like Ruby's:

x = 'Zed'
print f"Howdy {x}"

I really like this new style, and I have no idea why this wasn't the formatting for Python 3 instead of that stupid .format function. String interpolation is natural for most people and easy to explain.

The problem is that beginner will now how to know all three of these formatting styles, and that's too many. When I update Learn Python The Hard Way to Python 3 I'm only going to teach the 3.6 "f-string" style, and then mention the other two only as legacy code.

Even More Versions of Strings

Finally, I'm told there is a new proposal for a string type that is both bytes and Unicode at the same time? That'd be fantastic if this new type brings back the dynamic typing that makes Python easy, but I'm betting it will end up being yet another static type to learn. For that reason I also think beginners should avoid Python 3 until this new "chimera string" is implemented and works reliably in a dynamic way. Until then, you will just be dealing with difficult strings that are statically typed in a dynamically typed language.