I have a gripe about how Python is being taught. Before I get into it, let it be known that I am a new Python developer. I do not have a vested interest in keeping 2.7 alive or in championing 3.0. It’s just related to learning a new language and how it’s being taught is rather frustrating.
There are several courses that are very well done and complete, on learning Python. I’ve seen that many of these courses are choosing Python 2.7 rather then Python 3.* Yet many new books on development in Python are only teaching Python 3.
The problem here, is that I believe it’s a disservice to the students learning Python as a programming language. There is a course on Intermediate Python at Udemy, and the teacher/trainer of the course refused to answer any questions related to Python 3 from his students. One student mentioned how something was different in Python 3, and he responded:
I use Python 2.7 every day, it’s good enough for me, it’s good enough for you. Once you learn 2.7 you can modify your code to 3, it’s not hard. –Udemy Instructor
I restated his question back to him with, “If updating Python 2.7 code is so easy, why not just update your lesson material to reflect the current release of Python, rather then a branch that goes back many years?”
Python and it’s split
As near as I can tell there is a division in Python where the community split when version 3 was released. Version 3 was not backwards compatible and introduced many changes to the Python language. Rather then slowly update 2.7 code, a strong undercurrent of refusal came about. This created two separate and equal branches! 2.* and 3.*.
Python 3.0 was released on December of 2008. As of this writing that’s 7 years ago! For 7 years there is an undercurrent of people refusing to upgrade to 3.0 and there is still maintenance and work on the 2.* branch?
That’s the equivalent of people still using Java 6 or Grails version 1.*.
What’s the Problem?
The problem is with any code base that splits and is maintained in separate branches… not everything gets updated on both branches. So one team developing one library on Python 2.7 refuses to make changes for 3.0 compatibility. Then another team working on another library builds it for 3.0 and refuses to make changes to 2.7. If you’re the unlucky dope who has a need of both libraries, then you have to weed out the incompatibilities of the two.
Beyond the multi-branch issue, there’s another problem. People learning Python 2.7 will take code that they think should work, but conceptually is wrong (but it works in 2.7) and then when they go on an interview they wonder why they are down marked for something like this:
Question: What’s the result of this code (source of code: edx class 6.00x from MIT professor John Guttag):
temp = '32' if temp > 85: print("Hot") elif temp > 62: print("Comfortable") else: print("Cold")
Answer: An error related to the type mismatch of strings and integers.
However in Python 2.*, the above code would print: “Hot”
Why would Python 2 print “Hot?”
Because Python 2 arbitrarily sets a notion that strings have a higher value then an integer (source: edx class from MIT professor John Guttag.)
But why? Is it logical to say, “Which is greater, ‘pig’ or 99?”
We’re comparing a string of pig to a number 99. What’s logical in that?
Python 3 will error on this and say something about TypeError: unorderable types: str() > int()
That seems like a logical thing to do in this case.
Rewriting of Code
Then there’s the constant rewriting of code. Arg. You take these online classes, and yes they’re great and free – but you have to rewrite the professors code so that it’s compatible with Python 3.
Why am I using Python 3?
Because for any Greenfield project (where I have the choice of what to use), I will always defer to the latest stable build.
Why would I do that?
So that I avoid the harsh utility cost of having to upgrade all my code later on, when it will cost much more in time and energy. At some point all these folks writing code that taps into 3rd party API’s will have to upgrade to 3.0… If you have a monolithic project and it’s code base is 2.* and that day comes when you need to convert it to 3.0…. good grief what a nightmare that will be.
Regardless of that, there are considerations of logic – the above example of a string being given a higher value then an integer is one of many reasons to make the change.
What if a job requires 2.7?
I guess that’s the rub. You either learn 3.0 or 2.7 and then have to switch gears when working the other language.
Thing is, if people keep placating 2.7, there move to 3+ will keep getting diverted. Ultimately something has to give. This is just becoming a frustrating aspect of development.
Think of it this way:
I’m a developer on a greenfield project. I’m told I can choose whatever language I want. I like Python, but this silliness with constant libraries that aren’t compatible with 2.7 or vice versa… makes a new decision tree:
Why even go Python? Why not Ruby? What about (god forbid) Java?
Look at What Happened with Groovy
I like Groovy and Grails, but one thing for sure, they are a limited scope market. Ever try and hire a Groovy/Grails developer? It’s like a needle in a haystack. If you think, “well just hire a Java dev and tell them to write groovy,” it doesn’t work out well. That course has been tried at a variety of jobs I’ve worked and it ins up with Java dev’s putting pure Java code into Grails apps and the end result is some bastardization of Java and Grails.
Ever wonder why Groovy is not as popular as Ruby or Python?
Groovy evangelists made a poor decision early on:
To preach Groovy as a viable scripting language ONLY to Java developers. They excluded a huge market of people new to programming. Pick up any book on Groovy and read the intro. I bet you’ll see something similar to:
This book is for Java developers. It is expected you have some familiarity with Java or an existing Object Oriented language.
Well that sort of sucks doesn’t it? Right off the bat new comers are excluded. But is it true? Is it necessary to learn Java first? Not at all! It’s the most absurd thought! It’s sort of like saying that one must first become a PhD in Physics in order to pursue a education in Mechanical Engineering. What a crock.
Google, “Groovy training tutorials” how many results are geared to the novice/beginner at learning programming? Now google “Ruby training tutorials” and then “Python training tutorials.” See the difference?
So Groovy was limited to Java dev’s… and of them, only a fraction are interested in using Groovy. Therefore the language limited itself even further into obscurity. Now as a company decision maker, try and hire a Groovy dev… well it’s few and far between… which makes companies rethink even considering Grails as a potential viable option for a web framework. While it might be great and cutting edge, if it has no talent pool behind it, it will come at a high opportunity cost (lack of diverse talent.)
If the Grails/Groovy community is too limited, then when Groovy jumps from 3.3 to version 3.4 and you don’t have a community strong enough to update the plugins… things fall behind (such as what happened with the Google Visualization plugin – which I used heavily… and then it broke in 3.2 of Grails… and the author said it was due to a mistake in the core Grails code. Grails refuses to acknowledge it… and a stalemate occurs…) A situation like that should never happen. But if the community behind it is too small, it will happen.
Is Python Doing the Same Thing?
Maybe. Ruby continues to explode in a market that really should be co-owned by Python/Django. Yet time and time again I see posts on Stack Overflow, “How can we get Python/Django to compete in companies in Silicon Valley?” In one such discussion a noted Python developer replied that if he had a small company he’d prefer to go Ruby/Rails simply for the supply of potential talent…. even though he preferred Python as a language.
Continuing to update multiple versions, is going to become a detriment, if it hasn’t already.
I love Python, but when I pull in a library like Pyshark to work in my Python 3 code base, I have to fork their code, go through all the errors where they aren’t compatible and resolve them before I can even use the library – what’s the point? What if I have a deadline? What if I’m in an agile shop and we don’t have time to make other people’s code work with what should be a standard?
I don’t care who wins, 2.7 or 3.*, but someone needs to win in Python so we can have a standard community code base.