Python is Trash

For convenience, section headers are clickable and will auto-scroll when links are copy-pasted. Clicking on the main header will fix that.

Bold statement, I know. Python is in a class all of it's own. It's better this way. In fact, Python is so uniquely garbage that I decided rather than explain this in bits and pieces, I'd write up some of the reasons why. This was written on October 18, 2020 for reference -- as this article gets older this will only get worse.

As the most painfully obvious flaw of Python, let's get this one out of the way. Significant whitespace is atrocious. It wouldn't be so bad if there was a way around it, some way to explicitly define sections of some sort. There isn't. Any time you get both tabs and spaces playing along nicely together, you require an editor that can visualize both. Or just keep it fresh in memory, but you don't exactly have the luxury of delaying at all with a boss breathing down your neck about a full-stop problem while telecommuting. (Remember -- what you learn in college, and apply at large companies, absolutely DOES NOT APPLY to smaller, "fly by the seat of your pants" style companies. Yes they exist. In large numbers. You've probably done business with a few without even knowing it. For these companies, very necessary on-the-fly edits become unnecessarily limiting.

"Just use a proper editor Julietta!" is an absolutely rubbish answer. It both ignores the limitations inherent in significant whitespace, but -- probably more importantly -- completely absolves a real problem by assigning blame where it doesn't belong. You don't always have access (or time!) for a proper IDE. Every Windows computer comes with WordPad. Loads up in milliseconds. I'll also note that I know of zero "proper" Android editor, let alone iPhone, though there are several fully functional text editors for both. If all I'm doing is changing a couple of lines and sending it off, it's ludicrous to require a full-fledged IDE for this. Or even a lightweight one. Besides, it increases the cost of entry for newcomers.

Whether or not whitespace matters to you, it does matter to some, which affects all by limiting talent. And that's not even getting into the rest of the syntax weirdness!

Speaking of IDE's...

Good question. I don't have an answer. Or rather, a good one. Even after pouring through a StackOverflow question on exactly this subject which is so incredibly technical it's hard to summarize it in any reasonable capacity, though I will try. Python is interpreted, but also compiled, in an overly complex way that really does absolutely neither at all. Is your garbage can getting full yet? Find a dumpster, this is gonna take a while!

Python calls itself an "interpreted language". An interpreted language parses the code directly and runs it verbatim. So Python does this too right? Actually, no, it does not. It never does. Python -- despite openly describing itself as an "interpreted language" -- hides away in the documentation that this is false.

This is true of exactly zero interpreted languages. None. Not HTML, not SQL, not Javascript, not Batch, nor Bash. These are all true interpreted languages. You just save files in text format and a compiler comes along and makes bytecode. Which is what a compiled language does. And honestly? Even if you can't run the code files direct, it is no different from a DLL. Except a DLL is a universally understood construct that has been -- and continues to -- work flawlessly. Python just does not like DLL's, and decided the solution to fixing DLL Hell was to create proprietary hell. You can create DLL's from numerous languages, all are interoperable. But for some reason, Python decided .pyc files were better, even though literally nothing else is able to use it. Like Tesla and their chargers. (Every good IT person has something to say about Tesla anymore, it's a rite of passage.)

Yes, you can compile it to an actual EXE if you so choose. This is a standard feature of any language capable of compiling. Neat. Not even the bible of an answer in that StackOverflow question -- which immediately dodges the point literally just to mention the bible -- seems to suggest Python isn't a start-to-finish language somehow. I don't know, you tell me.

But hey, at least it runs on every platform without issue right? Oops... about that.

Not "rights", because it has none. It never did. Linux/Unix support was always in-built, this much is true. But Windows was tacked on. Like .NET and Mono. I don't see much love for C or C++ but they're truly cross platform, just in a more difficult and roundabout way. It used a framework embedded in the application to accomplish the task, always, in a way that never worked well.

Anyone familiar with diagnosing incompatible Python frameworks on Windows will know exactly what "path" refers to. And yes, it is this same path that is faulty. Because it relies on it. Which isn't helped by the 2.x/3.x weirdness (more on that later!). Meanwhile, .NET literally needs only one framework to be installed -- the most recent one. Yes, you'll see a bunch of VS2008 etc. frameworks being installed left and right, these aren't strictly .NET however. But you can still take a Python codebase and just compile to Windows no frills right?

Literally no. Never. This isn't possible. Entire build toolchains rely on individual people to know and understand how to build it on Windows. Take a look at open source projects that push a lot of versions but don't have many people on them (Meld Merge is a great one), there is a constant struggle of "the build is failing and we don't know why." This isn't any more "cross-platform" than taking a taxi. Sure, once you tell it what to do, it can work mostly fine, but occasionally there's some construction or the driver is directionally inept. One guy can't get there and needs help to figure out how to get there. Not good. Is it able to run on all platforms? Yes. Is it easier than other languages to do? No, it never has been.

But let's assume you have that sorted out too. Time to show off your mad UI/UX skillz right? About that.

A fundamental part of any desktop application is the ability to have a natural feel to the program involved. This, for some reason, is absurdly hard. It doesn't pass as natural. it doesn't even try to pass. Like Joan Rivers, it almost seems to brag about it. Python apps almost universally have their own "feel" to them. Nevermind the limitations of Tkinter. A truly professional software package will look the part. Professional. Appealing. Weirdly, for some reason, this is hard.

The most common thing I hear about Python apps from those that aren't fans of FOSS (or of an older generation but that's neither here nor there) is that they usually "look like a child's toy, made for kids." Yes, I have heard this one repeatedly. But the reason is rather simple -- Python apps have a tendency to be built for -- and run on -- Linux. From Inkscape to VLC Media Player to GIMP to (yes, again) Meld Merge, they universally follow Linux UI practices. These UI practices gear more for general use, while Windows gears more for a professional environment. They are literally designed in this manner. So okay, this is fair, right?

Well no. Some of the most popular FOSS software packages -- including category-dominating ones like VLC and Inkscape -- design with Linux UI. But as of Q4 2020, the market share makes this an outlier. A major outlier. 77.12% of the market share belongs to Windows, with Linux sitting at 1.74% market share, which means that for every one person that uses Linux, 44 use Windows. Still, there are plenty that pack on outdated "theme" engines that invariably include Office XP for some peculiar reason. XP is fully dead now. But it still managed to do things right. And so did Microsoft Windows as a whole. Windows 7 now works with every single XP program in existence, or damn near close to it. Backwards compatibility is wonderful sometimes.

So... about that too.

Python 3 is NOT compatible with Python 2. Python 2 EOL was at the very start of January 2020. It is no longer supported. At all. The codebase is now ripe for security exploits with zero way to correct this. Python announced the death of 2.x only two and a half months before EOL I cannot stress how disgustingly awful this is. From announcement to end date, three months managed to -- in very real ways -- cause a stock market dip that directly affected the pocketbooks of many investors. This announcement came at a tangible price. A financial loss. A harmed reputation of JPMorgan and others. Python 2 managed to enter the nationwide news cycle for weeks in the worst of ways because of a three-month deadline. This is something that is inexcusable for a number of reasons. And honestly, my biggest -- by a long shot -- complaint about Python as a whole. No professional coding language would ever do this. So how did Python manage to?

"That's too aggressive Julietta, they announced it in 2008!" Well yes, for a 2015 end date. Then in 2014 not enough people had switched, so they extended it to 2020. In mid-September 2020, they declined to extend it further. In the sunsetting announcement (which is really just a non-standard word for end-of-life), the first three words are -- by far -- the most important.

"We are volunteers"

One of the biggest coding languages is run by volunteers. This isn't knocking volunteers (hell I am one myself), or even FOSS, it readily enters the frame of mind that kept Windows XP from meeting the same fate. Windows XP was released in 2001. In 2008, it received its final update, two years after Vista had entered the scene. Yet still, for a sum total of 19 years -- almost two decades -- XP was available to businesses in a supported manner. April 9, 2019 was the final end date of Windows XP. Python lasted 12. This seems good on its face, keeping up, but the reality is far different. Queue the distinction between migration and forced switching costs.

Windows XP reached EOL with a readily available migration path -- Windows 7. Since the introduction of Windows 7, Microsoft made a giant push in to the professional world for all businesses to use it. Microsoft went out of their way, repeatedly, to allow the transition from Windows XP to Windows 7 to be as smooth as possible. Microsoft made an active effort to minimize -- or even outright invalidate -- switching costs. Python made zero such attempts and if anything actively fought this.

So, what are "switching costs" anyway? In the business world, any time you have to "switch" from one thing to a different thing, there is a "cost". Retraining employees, rewriting things, porting over codebases, sometimes layoffs and new hires are required if the change is drastic enough (yikes!) This is a very real business problem, one that is hard to justify without thinking long-term. After all, what do you get from switching? It has to be beneficial somehow. It has to earn the business money, whether it's by efficiency, or more capabilities, or reduced costs long-term, there has to be a benefit to ditch something that works for something else. This is one of the many, many reasons COBOL is still in widespread use. Sure it's old, but it works. It's a well-oiled machine. And it's never needed to be changed.

The transition from Windows XP to Windows 7 was designed to make this next to (or outright) zero. Python made zero attempts in any capacity to do this. In fact, by design, it is literally impossible to switch. If Python were run by a company, there would be several lawsuits to this end. Hell, JPMorgan alone had enough reason to go to court over financial losses and reputational damage. Exercising authority over someone and actively cutting them off by choice usually leads to lawsuits. Python -- by virtue of being the single largest dependency on JPMorgan's code base -- is inherently prone to this. So how could you avoid this?

Gee I dunno allow Python 2 to still work in Python 3? Actively deprecate files and syntax to do the job? It hasn't changed much. Allow for a header in the Python code files to signify a Python 2 code file in a Python 3 project? Out of every single language in major use today, Python is the only language that felt it necessary to eradicate all interoperability with a version change.

Perhaps most disgusting is the sheer quantity of FOSS Python 2 code bases that aren't maintained anymore and are immediately prone to security exploits -- soon being just outright unsupported. As a fellow volunteer, you want your work to leave an impact, a good one. This is a slap in the face to that mindset. A few volunteers managed to overturn the world's priorities for twelve years out of a refusal to figure out interoperability. They still haven't. And have no plans to.

There are still job postings - after the EOL date of Python 2 -- that are being made new in an attempt to convert Python 2 to Python 3. None for major companies, those have already figured this out. Small ones with codebases that have been built for years on this concept are the most vulnerable. It's showing.

As a language, Python is trash. But as a concept, on its whole, as a destructive force, it's not just a dumpster fire. It's the entirety of the world's garbage collection system violently exploding. Now don't get me started on Javascript!!!

- Julietta

[Back to Code Monkeying Around]