The Case Against “The Case Against Python 3”

Patrick Westerhoff
25 min readNov 23, 2016

Zed A. Shaw recently published an article called “The Case Against Python 3” in which he tries to argue that Python 3 is a dead language and nobody should ever use it but continue the deprecated Python 2. It’s actually Python 2 that is considered dead.

This is a response to that article, attempting to point out everything wrong with it, and hopefully showing you why believing that Python 3 is dead is just plain wrong.

Note: I wrote this mostly on impulse, without actually caring much how the final format would end up. I only realized after the fact that this turned out so long that it would make sense to publish this properly. I’m leaving the original format though.

Note 2: I realize that this post may appear a bit harsh in regards to Zed’s opinion. I really don’t mean to do any harm. I believe that Zed’s intention of teaching beginners programming languages is really admirable. But I also think that over the years, one starts to shift too far into ones own comfort zone, while stopping to learn new things and accepting change. I hope that this post helps realizing exactly that. I’m happy to discuss this further and hope that we eventually end up with a happy community that embraces Python 3 as it is.

Initial sections

I cannot teach Python 3 to total beginners because I don’t want them to think they “suck at programming” when really it’s Python 3’s fault.

If you say you can teach people Python 2 but are unable to teach them Python 3, then you just “suck at teaching” for a lack of better words. The fact that you still teach Python 2, claiming Python 3 being broken, appears to be a lazy excuse not to change your teaching techniques which are ineffective to begin with, something we have been saying for a while…

Python 3’s adoption is really only at about 30% whenever there is an attempt to measure it.

[citation needed]… It is true that Python 3 had a difficult start, and is still suffering from it. However, the reason for this is not really that Python 3 is inferior to Python 2, but rather justified by the sheer amount of legacy systems using Python 2. Python 3 was by-choice a backwards-incompatible update. This has the side effect that applications and libraries built for Python 2 did not work for Python 3 but had to be ported. This is a complex process and takes time. As libraries weren’t ready for Python 3, application adoption for Python 3 also didn’t progress further.

But it’s 2016 now, and a lot of time has passed since the initial problems. Nearly all major libraries now have full support for Python 3 (see Python 3 Wall of Superpowers and Python 3 Readiness). And the general adoption is actually increasing.

if you’re planning on using Python 3 in the future you will most likely be in trouble

This is mostly your opinion, based on arguments you are listing further down. But the actual fact is that continuing to use Python 2 in the future will actually cause you trouble. You still teaching Python 2 is really teaching people a dying language because after its end-of-life in 2020, nobody should be using the language for production anymore.

If you learn Python 2, then you can still work with all the legacy Python 2 code in existence until Python dies or you (hopefully) move on.

On the flip side, you also have to deal with all the legacy Python 2 code in existence and cannot rely on new language features, or a consistent language that decided to remove debt (instead of building onto it like e.g. PHP). You will have to deal with all the issues from the past and will eventually run out of library support, and security patches. Or, you decide to move on, which means that you would now learn a language just to stop using it in less than four years.

“Reasons Beginners Can Grok”

The first section is aimed at beginners.

“Not In Your Best Interests”

Ask yourself, why are they so keen on having you use a language that has only about 30% adoption […]

I don’t know why you keep insisting on this “30%” adoption (regardless of whether that number has any truth or not). If you just talk about learning a language, you shouldn’t just put Python 3 next to Python 2. You should put all languages next to each other. Yes, Python summed up is a popular language. But it only sits there with currently about 3.5%.

Now, there are people who invest time in learning a lot less popular languages, e.g. R at 1.7% or even assembler at 2.4%. Are you saying that these languages are less useful because they have less “adoption” among programmers? One could even go as far and say stop learning Python altogether because languages like Swift and Go are steadily getting more attention, so in the long run they might be even more popular!

But that doesn’t matter. Popularity or programming language adoption is mostly irrelevant. What matters more if the language works well for you and can do what you want it to do. Most languages offer that, so it boils down to personal preference. And fact is, and you generally seem to agree with that, that Python is a language that’s very well suited for beginners. It’s easy to learn and among the more popular languages has little surprises.

[…] is constantly changing

Change is a good thing! Languages should continue to evolve all the time. And in fact, all languages do that: JavaScript, C#, Java. Even PHP, the language that has likely the most depressing debt on a language level is evolving in crazy ways trying to make up for the past. And tell you what, I think it’s progressing very nicely and continues to evolve into an actually well designed language.

And of course, Python 3 is evolving too. The asynchronous stuff alone is worth it enough. Anyone who has used async/await in other languages (C#, JavaScript), will likely tell you that they would never want to go back. So we should be glad that we have support for it with Python 3.5 and Python 3.6.

But there’s one thing that is not evolving: Python 2. Do you really want to continue using a language that will not be able to aid you as the programming community discovers new ways of being productive without spending time on tedious stuff?

[…] and full of issues?

Show me one thing that is actively being used that has no issues.

They only care that you, a beginner, will amount to one more user.

[citation needed]. No, that’s just stupid.

I want you to just get started programming and that is all. I don’t care what language you use

Then teach Python 3.

The language doesn’t matter to me at all

Yet, you’re teaching Python 2 only.

and I’m not going to push a broken language on you.

Then take down your book?

Some people go so far as to ban my book because it does not support Python 3

Yeah, that would be one valid reason to avoid your book.

even though my book is the most effective method for learning to code

[citation needed]. Seriously.

It would just naturally work for you and you wouldn’t have any problems.

Guess what? That’s exactly how it works for a majority of people. Using Python 3 is not a problem. Sure, you run into problems, but you do that with any language. And I can honestly say that I’ve run into more issues with Python 2 that were the language’s fault than with Python 3.

the Python project uses propaganda, social pressure, and marketing to convince you to use it.

[citation needed]. And here you are, doing the same telling people to avoid it?

In the world of technology using marketing and propaganda is immediately a sign that the technology is defective in some obvious way.

“You Should Be Able to Run 2 and 3”

First of all: Why? If I write something in language X, I don’t expect it to work in language Y. It turns out, writing a program that does this is really hard. Yes, Python 3 and Python 2 both are both Pythons, so it should be easier. But Python 3 is by-design backwards incompatible, so you cannot just expect it to work.

And if you want to build things that run in both versions, there are ways of doing that, and tools to help you (e.g. Six, Python Future).

In the programming language theory there is this basic requirement that, given a “complete” programming language, I can run any other programming language.

[citation needed] Wat. That’s just not true at all. If you’re hinting at Turing completeness, then you’re just wrong. Turing completeness generally means that you can implement a program that can be implemented by a Turing complete language, using any other Turing complete language. That does not say anything about the way that language is expressed with. It doesn’t mean at all that you can run one programming language within another one (which is also not the case for most languages).

In the world of Java I’m able to run Ruby, Java, C++, C, and Lua all at the same time. In the world of Microsoft I can run F#, C#, C++, and Python all at the same time.

I don’t even know what you are trying to say here. I can easily run a Python 2 and a Python 3 application at the same time on the same machine for what it matters… I’ll just ignore the rest of this section because it makes no sense.

“No Working Translator”

Note what you are referring to as “translation” is simply called “compilation”, or in case of intra high-level compilation “transpilation”.

Python 3 comes with a tool called 2to3 which is supposed to take Python 2 code and translate it to Python 3 code.

To quote the documentation: “2to3 is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code.”

The 2to3 translator fails on about 15% of the code it attempts

2to3 is a tool that aims to help you migrate your code. It cannot do wonders, and since Python 3 is deliberately a backwards-incompatible update, you cannot really expect it to work magically. Yes, even with all the transpilation stuff working for other languages. If you’ve ever looked at transpiled code, for example for all those compile-to-JavaScript languages, you would know why this is not an application of transpilation.

The code migration to Python 3 is something that should be done once, in order to continue working on the migrated code base. So after a successful migration, you would not continue to edit the original Python 2 source but you would edit the new Python 3 code. This means that the resulting code should be succinct and proper Python 3 code. That however is not something, code transpilation aims to do. Code transpilation has the goal to allow you to write a different language (and continue writing that language) while getting executable (not even readable) code in a different language.

“Difficult To Use Strings”

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

[citation needed]. I personally think the strings in Python 2 are very difficult for anyone — not even just beginners. Or should I say unicode strings? No, both. Why even have two string types for readable text?

you’ll have to understand the difference between byte sequences and Unicode strings. Don’t know what that is? Exactly.

The difference between a binary blob of stuff and readable strings..? Yeah, that’s really difficult to understand…

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.

Yeah, because before everything was so much better. You had a string type that was used for both binary content and for ASCII-like strings, and the only way you could tell that something was one or the other would be to print it and see if you have readable content or not. Want to input non-ASCII characters because you are building a modern application that deals with more cultures than just your own? You might need that other string type which is incompatible to the string type exposed by most APIs and which you have to convert inbetween all the time without really knowing what state you are in.

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.

Old-style percent formatting is still supported. The other way is using the new string formatter. Yes, it’s maybe a bit more complex but it’s also way more powerful and actually easier to understand. Just read the documentation and look at the examples. It’s not that hard. But of course, you don’t have to use it. It’s an optional API you may choose to use or not.

Not even I, an experienced professional programmer, can easily figure out these new formatting systems or keep up with their changing features.

I’m sorry, but this does not really help you make your case. If you can’t even figure out a simple string formatting API, then I don’t know what you should do…

As for changing features, the API is very stable since its release, so I’m going to have you cite some actual changing features there.

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.

I’m going all out here and just say that you appear to have no idea what you are talking about. The fact that you apparently can’t really tell the difference between bytes and str in Python 3 makes me believe that you simply don’t have any clue about Python 3 to begin with. Which makes it really hard to take any of your complaints seriously. You appear to be fixated in your belief that Python 2 is the only viable solution here, and you further seem to be so disconnected from the “beginner” experience that you are unable to estimate what actually becomes a problem for beginners and what not.

For beginners, it’s much easier to grasp the difference between bytes and str than for those who have been accustomed by the mix that Python 2 was. And it helps even more if they can put any text into a string, instead of having to choose between two actual string types depending on whether they use non-ASCII characters or not. After all, one of the biggest gotchas with Python 2 was always the bad unicode handling (which is exactly the reason why this was changed with Python 3). And no, beginners usually don’t need to know about bytes, and when they do, they usually wouldn’t expect it to be compatible with str anyway.

When you start out programming the first thing you work with is strings

Sure; just str. Not str and unicode. That appears easier to me.

I mean, if I struggle to use Python’s strings then you don’t have a chance.

No. If you struggle with Python’s strings, then I’m sorry but then you just appear to be bad at programming; or bad with change.

“Core Libraries Not Updated”

Many of the core libraries […] have not been updated to use its features.

So? New features are not mandatory to use. Why change working code that performs well? If it bothers you, and you have a reason to change it, feel free to submit patches.

given Python 3’s constant changing status

[citation needed]

when a library could detect Unicode

There is no need for a “Unicode detection”. There is only a single string type, why would you want to detect anything there. Stop treating Unicode as the special thing but make embrace it fully. It’s everywhere now anyway, so don’t shut it out.

it fails to do so and returns raw byte arrays.

Usually, there is a very clear definition of when something returns a string and when it returns bytes. Strings means you have text, bytes means you have some binary content which may or may not be text but since you have no encoding information you cannot safely decide about that. If you know better, then just decode the bytes into str.

have your code explode with a weird error message that has no variable names in it.

I’ve written a lot of Python code, and read even more error stack traces, and I could always tell what the problematic thing was. Why can’t you? Understanding error messages is one of the core competences of a professional programmer.

This then is randomly distributed

So you just write bad code, that is not deterministic and you have no idea what you’re doing.

the Unicode status of data

I don’t think “the Unicode status” is a thing.

Until there is a standard for what every library should return

Libraries are luckily able to define their own interface. It would be pretty difficult to design a library if there was a standard dictating what I could do. If you don’t know how to use a library, cannot understand it, or it simply doesn’t work the way you want it to, there is a simple solution: Stop using it.

“Reasons For The Programmers”

This was teasing to have more technical reasons…

“Python 3 Is Not Turing Complete”

In computer science a fundamental law is that if I have one Turing Machine I can build any other Turing Machine.

“Fundamental law” is already wrong since Turing completeness is not required by anything. Sure, most languages are Turing complete, so you can expect them to work according to the definition of that. But it’s not a requirement.

However, you still seem to miss what Turing completeness means. Maybe you should visit a course. Or at least read the article on Wikipedia.

If I can’t use your language to write a compiler or interpreter for any other language then your language is not Turing Complete.

Currently you cannot run Python 2 inside the Python 3 virtual machine. Since I cannot, that means Python 3 is not Turing Complete and should not be used by anyone.

Even if I were to use your definition of “Turing completeness” here, saying that one language is “Turing complete” if it was able to write a compiler and/or interpreter for another language; then Python 3 would still be Turing complete:

Yes, you cannot run Python 2 byte code within a Python 3 virtual machine. That’s because the VM is built to exactly only interpret that one byte code language version.

  • Can you write a compiler with Python 3 that was able to compile Python 2 source code into Python 2 byte code? Sure.
  • Can you write a compiler with Python 3 that was able to compile Python 2 source code into Python 3 byte code? Absolutely.
  • Can you write a virtual machine with Python 3 that was able to interpret Python 2 byte code? Odd idea, but why not?

So, even by your own wrong definition, Python 3 is Turing complete.

Just because I cannot run code for language (version) X with Y, that does not mean that Y is not Turing complete. Otherwise, your other examples wouldn’t work either since I cannot paste in my FORTRAN code into a COBOL compiler and expect it to work. Or use assembly code for a ARM processor and expect it to work on a x86 machine. You can build programs that are able to simulate it though; and that’s what Turing completeness is about.

there’s no reason why Python 2 and Python 3 can’t coexist other than the Python project’s incompetence and arrogance.

Speaking of incompetence and arrogance, you keep putting out “facts” here that are just very misinformed and wrong just for your own agenda. In order to make an actual argument against something — anything — you should actually have the competence of knowing what you are talking about.

actual Python project developers have told me this

[citation needed]. And of course, just because someone says something, that doesn’t make it automatically true. And it’s even more likely that you just misinterpreted what they said here.

“The JVM and CLR Prove It’s Pointless”

Remember how I said, if I have one Turing Machine I can make any language run on it?

Yeah, I remember, and it’s still wrong.

A virtual machine makes this process easier because I can use the virtual machine’s bytecodes to disconnect the particulars of any langauge’s[sic] syntax from the execution requirements of a platform.

That’s actually completely backwards; maybe even more than just completely.

The byte code that’s relevant for virtual machines is the byte code that is generated by the compiler of the high-level language. The VM itself has no byte code; it interprets byte code. The reason why virtual machines are used is not to handle multiple different source languages. That is just a side effect (used e.g. for .NET with C# and VB.NET). The purpose of virtual machines is to create a consistent environment that code can run it, regardless of the underlying platform. So you can execute the same byte code using a virtual machine running on a x86 processor and on another virtual machine running on an ARM processor.

In fact, you don’t even need byte code. You could write a virtual machine that just interprets the raw source code directly. So what’s the deal with byte code? Compiling into byte code first allows you to have a flexible high-level source language that supports a lot of features which are difficult to implement. By compiling it down into byte code, you have a safe ground you build your virtual machine against.

The important thing is that virtual machines are not magic “interpret-any-bytecode” devices. They are highly specialized interpreters of byte code, running on a various number of platforms.

By replicating a CPU in software

That’s not what a VM does. It’s not a CPU emulator, that would be far too slow. It’s operating at a much higher level. Have you even ever looked at Python byte code? That are not CPU-like instructions.

The interesting thing about virtual machines is, once I have a bytecode for it, I can then simply compile any other langauge into that virtual machine and it will work fairly well.

Wrong. Virtual machines are usually highly opinionated on the source platform/language. Sure, you can write a compiler that compiles your favorite language into byte code for your favorite incompatible virtual machine. But chances are that it simply won’t perform that well because the virtual machine assumes different things, and you cannot bend your language that way.

Yet, for some reason, the Python 3 virtual machine can’t run Python 2?

Simply because nobody wrote a compiler for Python 2 source code that targets Python 3. And why should they? Python 2 is dead for all that matters. And why would you want to continue using an inferior language anyway? Python 3 is much easier to write and is constantly expanded with new features.

You don’t have a C to Java VM compiler either. Why? Because that would be stupid. C is far too low level to be useful when simulated on a Java VM. So is the JVM bad because of that? Obviously not. So why is Python 3’s VM bad then?

(I’m going to ignore all the following stuff of this section that continues on these wrong understanding and claims)

“Purposefully Crippled 2to3 Translator”

As already written above, 2to3 is not a transpiler, and it has a very different goal. It is not there to run Python 2 code within Python 3. Doing that would probably relatively easy to do, but it likely wouldn’t create a maintable Python 3 source. But that’s exactly 2to3’s goal: To have a one-time process to migrate Python 2 code into Python 3, to then continue working only with the resulting code.

In addition, 2to3 does not aim for full compatibility. It does simple translation tasks, mostly focusing on syntax changes that makes Python 3 code incompatible to Python 2 code. You are still supposed to test your code afterwards and continue to improve it towards Python 3 compatibility.

is a fully proven and fundamental piece of computer science

I’m not sure you know what “proven” means in the context of computer science.

There is simply no technical reason why 2to3 can’t be 100% reliable

Then do so. Submit patches to it, to make it 100% reliable. Make sure you include proof that your resulting tool is then 100% reliable though.

They cannot have it both ways and claim that translation from Python 2 is impossible and also that Python 3 is usable.

You’re right. One thing has nothing to do with the other. And nobody said it’s impossible anyway. It’s just not worth it.

should work perfectly

Somewhat unrelated but please show me code written by yourself that worked perfectly.

My belief is […]

I’m sorry, but your beliefs are very irrelevant.

this is totally unnecessary because Mr. Turing says it’s unnecessary

As per explanations above…

“Statically Typed Strings”

Python is a dynamically typed language. That means I do not have to know the type of variable to use it.

That’s not what dynamically typed means, but sure.

As long as it behaves like another type, I am free to effectively pretend it is that other type.

This is duck typing.

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.

So you are complaining that you get an error when passing something that is not a string to a function called add string or (con)cat string? Have you tried the same in Python 2 with an int (which is also not a string)?

Stop selling the arbitrariness of Python 2 string types — the fact that you never know what you have and what you get out of it — as a feature. It’s a terrible design that leads to many issues and inconsistencies.

There is no technical reason for the Python 3 version to differ from the behavior of the Python 2 version

Yes, there is. They removed arbitrary and hard-to-grasp behavior from the string types. They fixed it to make it work the same way as other incompatible types.

no place in a language for beginners

Python is no language for beginners. Python is a mature and professional programming language. Yes, it works well with beginners, but that does not mean that it’s a language for beginners or that we should ignore all the wrongs with it and just leave them there because “they have always been there” and it’s supposedly “easier for beginners” to have confusing things mix up clearly defined behaviors.

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

Traceback (most recent call last): File “”, line 1, in File “”, 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.

Left operand is bytes, right operand is str.

“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 strings are not statically typed. No idea where you get this from. Maybe you are referring to the fact that Python is strongly typed which means that objects have a type and behave according to their type and cannot be bent to behave like other types (so no implicit type conversions). However this is not special to Python strings, it applies to all objects in Python. So by removing implicit type conversions between strings and bytes (which would be impossible to define safely anyway), Python is just consistent.

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.

I read this as: “In the past, I didn’t have to care about what I was doing because I was lucky enough that it worked out well.” Saying you didn’t have a clue about what you were doing isn’t really smart. Why don’t you know whether you are concatenating bytes and (unicode) strings? Why do you even believe that doing so silently is a good idea? If you have such different types (with different semantical meaning), then you should never concat them. So yes, I consider it a feature that concatenating a bytes and string object fails in Python 3.

Strings are also most frequently received from an external source, such as a network socket, file, or similar input.

And when you consume that external source, you are the one to decide how the source data is interpreted. If it’s a text file, read it as a text. If it’s a network request and the response is text, read it as text. If it’s some binary content, read it as bytes.

This is the thing with Python 3: You do have a consistent experience there. You don’t consume some source and don’t know what you get back. You always deliberately decide how the content is interpreted. So you will not get surprises by design.

“Core Libraries Not Updated”

There are several libraries that, despite knowing the encoding of data, fail to return proper strings.

There’s only a single string type. If you receive a binary result but know the encoding, just encode it. Otherwise, it might not be text after all. If the library does not do that for you, maybe it doesn’t know the encoding (e.g. open takes the encoding as an argument), or maybe it simply wasn’t built to interpret any encoding.

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.

You might have noticed, the HTTP libraries in Python are pretty low-level. So they usually do not perform any magic conversion for you. Things like HTTPResponse.read are described to return bytes, so that’s always what you’re going to get. You will never get a string from it, even if the response may include one of the many Content-Type header values that says that it’s text. So you will have to decode the string yourself if you see an appropriate response header. Or use a higher-level library like requests.

In fact, I’d like to see this:
x = bytes('hello', 'utf-8') y = x.guess()

You want a function that is non-deterministic by design? I’ll pass, thanks, I don’t want my programs to guess for me. Usually, I know what I am doing, or at least that’s what I am aiming for.

it’s not magic to guess at the encoding of a byte stream

It kind of is though. I’ve seen so many automated tools guess some file types based on content and fail so hard. I can’t tell you how often I operate with other Git repositories that contain files where Git is unable to see that it’s actually text. Sure, it often works, but in far too many cases, it arbitrarily does not work. So I would rather not have such a functionality built-in. If I decide that it’s a good idea to run content-based detection, I can still do that at any moment deliberately by using a library that does that. But in general, I know better what content to expect that some automated mechanism.

The only reason this isn’t done for you is that the Python project decided that you should be punished […]

Yeah. Right.

“Too Many Formatting Options”

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.

String interpolation is not a fits-all solution. It does not work when the format string comes from some external source for example. A very common example would be internationalization: You have resource files that define strings which have placeholders. The placeholders are then replaced at run-time with values. That’s not something string interpolation can do.

Also note that just because you have interpolated strings, you still need the format string syntax if you don’t want the normal str() result of the value. So you don’t need to call str.format() but the rest still applies completely.

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.

Then you’re just making your book worse than it is. Just because you don’t get why you would need format strings over interpolated strings, that does not mean that they have no use case.

Article conclusions

Each year I would attempt to convert some of my code and write a couple small tests with Python 3 and simply fail. If I couldn’t use Python 3 reliably then there’s no way a total beginner could manage it.

If you are still unable to convert your “small tests” after all these years, maybe it’s not their fault but your own?

I’m hoping that writing this list will prompt some kind of change, but I doubt it. As the versions of Python 3 progressed — and the adoption was lacking — the Python project started using social pressure, propaganda, and marketing to gain traction instead of fixing Python 3’s obvious usability problems. This is a dangerous position because it is easy to fix problems that are seen as simple technical or usability flaws. It is very difficult to fix problems that are erroneously viewed as positive social goods.

Currently, the state of strings is viewed as a Good Thing in the Python community.

I’m honestly baffled that you keep bringing this up everywhere. As I went through what you have written closely to write this response, I’ve increasingly noticed that this is your main argument of everything. In almost every section you keep bringing up your personal problem with the string types. You keep insisting that the new situation is inferior without actually giving arguments. You just keep saying that you cannot use them.

The brainwashing goes so far as to outright deny the mathematics behind language translation and compilation in an attempt to motivate the Python community to brute force convert all Python 2 code.

The only brainwashing I see is coming from you, as you are trying to make your personal issues with the changes and your inability to understand the actual concepts behind things an important reason to refuse language progress.

The brutal truth is if Python 3 had been designed to run Python 2 and 3 code together […]

But it wasn’t. Python 3 was deliberately made as a backwards-incompatible change to Python 2. This was done well knowing that this would cause issues with legacy code, but it was decided to do this in order to move the language forward.

I fear that everyone who currently codes Python 2 is simply going to move to a more stable language like Go, Rust, Clojure, or Elixir.

Age of these programming languages in order: 7 years, 6 years, 9 years, 4 years. Age of Python: 25 years. Even Python 2 is 16 years old.

You really cannot compare that, and calling these languages “stable” compared to Python is just ridiculous. And still, if people want to work with those programming languages: let them! That’s the beauty of this whole deal: You can use the tools that make most sense to you. If that means you want to leave Python behind because you no longer feel at home with it, then do that. But don’t go around saying that it’s broken just because you no longer can keep up with the changes.

Which is probably why the Python project focuses on convincing unsuspecting beginners to use Python 3.

[citation needed]

It means beginners will fail at learning to code not because of their own abilities, but because of Python 3’s difficulty.

[citation needed]

My book is already banned on many Reddit subreddits, and various high profile Python project members work fairly hard to censor it because of my stance on their strategy.

Your book just has serious issues.

Conclusion

To be honest, when I was starting to read your article, and saw that you had two sections, one for beginners, the other one more technical, I was actually really curious what facts you would cover. Little did I know that both sections essentially covered the exact same content but just explain the same issues with different but similarly wrong words. You failed to cite any sources on your many claims, and you showed repeatedly that you don’t really know what you are talking about.

I get the impression that you are just bitter about being left behind by changes you cannot keep up with. I can understand that this is disappointing but this is not a problem of the language or the team behind it.

— poke

--

--