On Sat, Feb 17, 2018 at 2:22 PM, boB Stepp <robertvst...@gmail.com> wrote: > This article is written by Nathan Murthy, a staff software engineer at > Tesla. The article is found at: > https://medium.com/@natemurthy/all-the-things-i-hate-about-python-5c5ff5fda95e > > Apparently he chose his article title as "click bait". Apparently he > does not really hate Python (So he says.). His leader paragraph is: > > "Python is viewed as a ubiquitous programming language; however, its > design limits its potential as a reliable and high performance systems > language. Unfortunately, not every developer is aware of its > limitations." > > As I currently do not have the necessary technical knowledge to > properly evaluate his claims, I thought I would ask those of you who > do. I have neither the knowledge or boB-hours to write a large > distributed system code base, but I am curious if Python is truly > limited for doing these in the ways he claims. > > BTW, I am not trying to start (another) heated, emotional thread. You > guys do sometimes get carried away! I honestly just what to know the > truth of the matters out of my continuing to learn Python. I suspect > there is probably some truth in his claims, but I am not sure if he is > taking things out of their proper application contexts or not.
1) Type safety. This is often touted as a necessity for industrial-grade software. It isn't. There are many things that a type system, no matter how sophisticated, cannot catch; for some reason, though, we don't hear people saying "C is useless for industrial-grade software because it doesn't have function contracts". Anyway, if you want some system of type checking, you can use static analysis (eg tools like MyPy) to go over your code the same way a compiler might. "The first glaring issue is that I have no guarantee that is_valid() returns a bool type." -- huh? It's being used in a boolean context, and it has a name that starts "is_". How much guarantee are you looking for? *ANY* object can be used in an 'if', so it doesn't even matter. This is a stupidly contrived criticism. > Python markets itself as a dynamically-typed programming language, > similar to Perl, Ruby, or JavaScript. The word “dynamically typed” has > a positive connotation, more so than “weakly typed.” Conversely, the > word “strongly typed” sounds more positive than saying “statically typed.” Those are all different terms, and all of them are misunderstood. They're not synonyms. > Python ships with a threading module; but due to how the Python > interpreter is implemented, it can only ever run one thread at a time. > This is due to the infamous Global Interpreter Lock (GIL). In an age > when the only computers around had a single core, this was > nothing to fuss over. Totally not true. The GIL does not stop other threads from running. Also, Python has existed for multiple CPU systems pretty much since its inception, I believe. (Summoning the D'Aprano for history lesson?) > Python is relatively slow compared to programming languages that > run closer to the operating system. The run time of the countdown > example above is orders of magnitude faster when implemented > in other language runtimes. Yeah, it sometimes runs a bit slower in benchmarking. And it's way WAY faster to code in. Case in point: I reimplemented an app in Python based on a C# (one of the languages the article's author touts as better than Python), and made a single file under a thousand lines long out of what had been two separate projects (a UI and a library), dozens of files, tens of thousands of lines, and tons of boilerplate that looks like this: https://github.com/geel9/SteamAuth/blob/master/SteamAuth/SteamGuardAccount.cs#L15 That's thirty lines of declarations to show how the JSON data translates into this object's properties. In Python, I just decode JSON to a dict, and then subscript that dict with whatever I need. Zero lines of boilerplate. So which one is more expensive? Hours and hours of programmer time, or a few milliseconds of runtime? > If you’re doing development on Mac or Ubuntu, you likely already > have Python 2.7 installed (Windows normally does not come with > Python pre-packaged). There’s a good chance that when you first > started programming in Python, no one told you about this thing > called Python 3 (no one told me at least). Ubuntu ships with Python 3 installed these days (and they're working on removing the need to have Python 2 installed). Macs ship with a lot of outdated software, so the correct thing to do is to install the latest anyway. If "no one told you" about Python 3, you don't know how to ask. And trust me, the Py2/Py3 gap is far less serious than the differences between version X and version X+1 of many JavaScript libraries. I know this for certain, having spent this past week resolving problems with React and related package. > Encapsulation and Packaging > ... > This is unsettling if you’re coming from a Java or C/C++ world and > are expecting access modifiers. They simply do not exist in Python. Yeah, it takes some getting used to. (Note that C doesn't have access modifiers either, so it's really Java and C++.) Did you know, though, that C++ is quite happy to let you cast a pointer to another type, and then ignore all the access rules? Yeah, but that doesn't bother people. Ultimately, you can always break past those kinds of protections. So why not put the protection into your source code instead of the compiler? The leading-underscore convention makes it obvious any time you "reach in" and manipulate private members. Sure, nothing stops you from doing it. But that's why we read code, we don't just run it. Yep, it's yet another hyperbole-filled article worded as click-bait. Fortunately it does have some content in it, but most of it is the same old complaints that have been known about - and solved - for years. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
