21–30 of 74 posts
That's not to defend Python versioning though, which as a sysadmin supporting devs is always a pain point.
"My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7."
Sure it will, just invoke it using the Python 3.7 interpreter. I have plenty of code originally written with 3.5 that runs just fine under 3.7, 3.8, 3.9, ...
"In Python, you have to work to pass variables by value."
No, you don't. Python actually doesn't pass variables "by reference". It passes object pointers, but you can't "mutate" an object pointer; it will always point to the same object forever.
What this author doesn't seem to get is that in Python, "variables" aren't labels for memory locations; they're namespace bindings. And unless you explicitly use the global or nonlocal keyword, nothing you do with setting variables inside a function will affect the caller's namespace. Which means that, in effect, Python variables are passed "by value" to functions--the function can only work with the object it was passed, it can't mess with the namespace it was passed from.
What does often trip up new Python programmers is that if you pass a mutable object, like a list or a dict, to a function, the function can mutate the object (add items, remove items, change what object a key or an index refers to). But the claim the author is making is much broader than that.
"Calling the same object by different names doesn't change the object, so it is effectively global."
I think this person simply doesn't understand how Python works.
Many of these things are annoying, but I wanna check something.... Lists in python are called lists because they're linked lists right? They are not called arrays because they are a different data structure. Edit: Well TIL! Thanks everyone.
> Lists in python are called lists because they're linked lists right? No. At the C level in the interpreter they are arrays of object pointers. > They are not called arrays because they are a different data structure. No. They're not called arrays because Python uses the name "array" for something else: https://docs.python.org/3/library/array.html
Overopinionated engineers are annoying. Python doesn't suck, everyone knows that. Every language has its strengths and weaknesses. Clickbaity.
(Slashdot wants their post back, haha.)
And the author mangles their Perl history as well. Perl 5 was (and is) by far the most popular version of the language. It was Perl 6 which started a decline, and that might have been due to an overambitious scope, a huge delay in releasing a production ready version, and an Osborne effect as much as much as due to incompatibilities.
"Reason 7: Pass By Object Reference": isn't this the case of almost every GC'd language? Java, JS, PHP, Swift, and C# all do so, although C# doesn't if your type is a "struct" not a class. Go is the only popular exception I can think of.
* Performance is very bad.
* Misspelling a variable creates a new one.
* __init__ is a really terrible name for the constructor.
* Type annotations are ignored, so nobody bothers.
"Reason 7: Pass By Object Reference": isn't this the case of almost every GC'd language? Java, JS, PHP, Swift, and C# all do so, although C# doesn't if your type is a "struct" not a class. Go is the only popular exception I can think of.
any language with immutability by default, say Clojure.
Although if I made a list it probably wouldn't match this one. Reason 1 and 2 are basically the same, and yeah this sucks and I wish I could just build a static binary like Go. I'm surprised more languages don't make this very easy!
Reason 3, I can't care about the whitespace debate anymore. But
> Deep nesting is permitted, but lines can get so wide that they wrap lines in the text editor.
??? This article is 5 years old, and we have black now to solve this; but I'm pretty sure most production code bases have had hard line limits in the style guide.
Reason 4,
> Finding a list of what can be imported is non-intuitive. With C, you can just look in /usr/include/*.h. But with Python? It's best to use 'python -v' to list all of the places it looks, and then search every file in every directory and subdirectory from that list
I don't think C/C++ is actually that much better at this?
> In contrast, many Python modules include initialization functions that run during the import.
They can but they commonly don't. A lot of python is about "we're all adults here", and that works surprisingly well.
Reason 5
> In every other language, arrays are called 'arrays'. In Python, they are called 'lists'.
I mean there's a good reason for that, and I don't think C++ would call that data structure an `array` either.
> Python seems to go out of it's way to not use the common terms found
Honestly CS loves to give +3 names to basic things all over, this isn't new to python. I don't think the author's chosen ones are correct.
Reason 6, I think newer languages are doing similar things with strings that python did, so I'm gonna say the wider community things this was a decent thing to do. And I'm not sure triple quotes is as complicated as =/==/=== in JS.
Reason 7,
> This means that changing the source variable may end up changing the value.
If you mutate an object I'm not surprised the change is propagated. But there are immutable values, notably strings, that will not work this way. I can't say this author shows much experience with any language in depth.
Reason 8, I don't think I've ever heard of someone complain about namespacing like this, and then compliment C.
These reasons all feel the like "it's not like the first language I used" rather than real issues.
What about default mutable arguments? What about namespacing of loop variables (and other wild ass shadowing rules when you do nested functions)? What about tooling??? You haven’t lived until you’ve made pylint or MyPy crash. And when they work, they are slow! And MyPy can be unstable in results on large code bases!