5 ms·

No offense to people who are good people and put in great effort, but that alone does not mean one is infallible. Python is a very poorly designed language, an

by z9znz 4y ago

No offense to people who are good people and put in great effort, but that alone does not mean one is infallible. Python is a very poorly designed language, and when I would sometimes dig to find out why things here how they were, Guido was behind many of the decisions which I believe were bad.

ironSkillet 4y ago
Python is a very poorly designed language...from your perspective...for a subset of tasks that you deem to have higher importance than others. I'm definitely not saying python is anywhere near perfect, and yes it certainly has design flaws (as does any complex system). But obviously it's done a lot of things right to gain the reach that it has.
- kimmeld 4y ago
  Being actively updated and maintained when Perl wasn’t helped Python dramatically.
- z9znz 4y ago
  > But obviously it's done a lot of things right to gain the reach that it has. Indeed it has. It is a very accessible (and even moreso "available") language. But it has so many odd (and frankly wrong) peculiarities that big projects tend to become more difficult more quickly because of the mess that is most Python code. Some of the footguns are so rediculous that you cannot believe they exist; and even more astounding is the apologist arguments for why they should be the way they are. This one is my favorite: https://stackoverflow.com/questions/1132941/least-astonishment-and-the-mutable-default-argument https://stackoverflow.com/questions/1132941/least-astonishme... Since it is so accessible and has such a rich ecosystem, someone with little skill can cobble together a system which works well enough to get to production. But that junior developer pay rate cost (and ease of hiring) will mean that as the project matures and more and more features are added, the code more rapidly becomes incomprehensible. Everything being mutable, no types (except for bolted on, visually noisy, non-runtime linters), OOP missing some of the key information hiding features, awkward or half-baked functional features, and time/space performance problems all combine to make Python a terrible choice for non-prototype level projects.
  - isitmadeofglass 4y ago
    > This one is my favorite: That’s not a confusing language design. It’s a very simple case of mutability that new programmers stumble over because they don’t yet know how to reason about mutability. But go ahead, tell us what should have been done instead here? Make it impossible to pass mutable arguments to functions? Or make it impossible to use mutable variables as default?
    - z9znz 4y ago
      It seems you are misunderstanding something fundamental about this issue. This is not a problem of mutability or immutability of function parameters, but rather that parameter default values are immutable. (But even to your point about making it impossible to pass mutable arguments to functions... that's a very common thing in many languages, even though it is irrelevant to this topic.) This should illustrate the problem: ------------------------------------- Python 3.10.6 (main, Aug 11 2022, 13:36:31) [Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def visit_city(city_name, visited=[]): ... visited.append(city_name) ... return visited ... >>> a = visit_city("Boston") >>> a ['Boston'] >>> a = visit_city("New York", a) >>> a ['Boston', 'New York'] >>> b = visit_city("Dallas") >>> b ['Boston', 'New York', 'Dallas'] >>> -------------------------------- Any reasonable developer would expect b to => ['Dallas']. You absolutely would not expect the value of b to have been influenced by previous calls to visit_city(). Python apologists only offer one positive for this: "It is useful for memoization". That is a very edge case use, and it was not the intention when default arguments were implemented. It was an accidental side use of a misfeature.
      - isitmadeofglass 4y ago
        > but rather that parameter default values are immutable. No they are not, I’d offer you an example, but you gave one yourself. Are you confused as to what mutable and immutable means? > You absolutely would not expect the value of b to have been influenced by previous calls to visit_city(). Yes they would. Python is not a functional language. If you have A=[1,2,3] and call A.append(4), what do you expect A to be? Same if you have a function with argument “mylist” and a default set to A, what do you expect to happen to A if you call mylist.append(4) inside that function body on a call that didn’t pass another list? > Python apologists only offer one positive for this: "It is useful for memoization". No, that is not the only use, if you couldn’t pass mutable arguments you would cripple the language. And if you couldn’t pass mutable defaults you’d have an odd inconsistent handling of them.
01100011 4y ago
Funny how two poorly defined languages, JavaScript and Python, seem to be dominating the world lately. It's almost as if people disagree with your assertion.
- z9znz 4y ago
  Bringing up Javascript really doesn't help your argument as it is pretty universally deemed a "poorly designed language". Many, many people have written about this. Somewhat randomly selected is this: https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f https://medium.com/javascript-non-grata/javascript-is-a-dysf... (and it references more). Later ECMAScript editions have made good improvements, but there are still plenty of sharp edges and footguns in Javascript which simply do not need to exist. Javascript is a leading language because _practically_ speaking (not strictly speaking) it is the only language you can use if you want to make things happen in the browser. And it came with every major web browser since the late 90s. THAT is why it gained immense marketshare. Python has been included in Linux, *BSD, and macOS for years. It's a very simple language to make things happen with little effort; it is "accessible" to most people, particularly non computer scientists. It reads a little bit more like English than other languages, and it doesn't require compiling (again to accessibility). All these things don't mean it's good. But it got picked up by non-developers and used to solve real world problems and a lot of research problems. More and more specialized modules were written for it, making it even easier to solve many problems. So its accessibility and ecosystem have been good. But that doesn't mean it's good for building big, long lived, easily maintainable or extensible systems. It certainly doesn't mean it's good for building performant systems. See elsewhere in this thread for my link to my biggest complaints (from an old discussion). I'm not a recognized expert on language design, but I've written significant quantities of production code in several languages, including Python, over many years. No doubt people may disagree with my assertion, but using popularity as evidence of disagreement is not valid since popularity often does not correlate to the quality or suitability of something. History is full of companies, technologies, and practices where the most popular was absolutely not the best.
- xdfgh1112 4y ago
  PHP was one of the most popular languages of the 2000s and was infamously badly designed.
kjeetgill 4y ago
> Python is a very poorly designed language, If you're going to throw around your words so sloppily like this at least give us a few decisions you don't like so we have something real to agree or disagree about, lol
- z9znz 4y ago
  I've covered this in detail before, so I didn't feel like rehashing it. Also, while in fact I did have a run-on sentence (because I failed to use a semicolon in one place where I used a comma), I don't believe it's reasonable to say my words were sloppy. See this thread if you want more than a few examples of how Python is poorly designed (as compared to Ruby): https://news.ycombinator.com/item?id=32116957 https://news.ycombinator.com/item?id=32116957
- IshKebab 4y ago
  I don't think it's really a controversial opinion though (except among Python fans, of which there are many due to how popular a teaching language it is). IMO the biggest issue is that they add features with absolutely no regard to how you could implement it with good performance. There are also a ton of features that let you do things that are just a really bad idea. Look at something like __subclasses__. Encourages terrible coding practices! (I learnt about it by reading some terrible code my colleagues wrote.) And good luck JITing that. There's also a ton of syntax that is weird and asymmetric, like list comprehensions. Also the fact that you don't need to explicitly create variables is very error prone. Some of that is excusable given how old Python is but that doesn't mean it isn't bad. Oh and import resolution. That's just downright terrible. No excuse there. I'd almost take #include over the insane mishmash of different ways imports work. It's even worse than JavaScript's module disaster.
skywhopper 4y ago
Yeah, the rationale behind many bizarre decisions always seemed to be “because this is the obvious right way”. Or “because Python favors clarity over magic”. And I’m just “how does that explain why len() is a root namespace method that takes a string arg, while isupper() is a method on string objects?”
- im3w1l 4y ago
  isupper makes sense only for strings, thus it makes sense not to put it in the global namespace. len is available for strings, but also lists, dicts and many other things. It's so useful that a 3-letter name in the global namespace is justified. Is there a reason for not making it a method though? Yes, actually. By using the dunder system, it makes len special. And it avoids a situation where some objects use a.len() others use b.length() and yet others use c.size() or d.len, e.length, f.size. Python has officially blessed the len name over the others, and that's useful.
  - z9znz 4y ago
    That defense doesn't really hold up. len() makes no sense for numbers, booleans, None, and probably other types I cannot think of at the moment. Python has a LONG list of built in functions, most of which are only applicable to a few types of parameters. They could just as well be object methods. https://docs.python.org/3/library/functions.html https://docs.python.org/3/library/functions.html Some of those methods, like sorted(), are terrible names. A past tense verb name... so instead of telling Python, "Hey, please sort() this", you say "Please give me a sorted() thing". So you have the collection.sort() method or the built in sorted() method. They both sort, but they have different options; and significantly, sort() mutates the collection, whereas sorted() returns a new collection. This is inconsistent and creates unnecessary cognitive load. It's another example of a Frankenstein language.
- bb88 4y ago
  This isn't magic at all. There is a method on all objects which are a collection: __len__() You can try it out yourself. x = [1,2,3,4] print(x.__len__()) #4 y = "abcdefg" print(y.__len__()) #7 z = { "a": "b", "c": "d"} print(z.__len__()) #2 len() is just syntactic sugar for calling __len__(). The "dunder" methods in python are a standard way of extending classes.

by z9znz 4y ago

ironSkillet 4y ago

Python is a very poorly designed language...from your perspective...for a subset of tasks that you deem to have higher importance than others. I'm definitely not saying python is anywhere near perfect, and yes it certainly has design flaws (as does any complex system). But obviously it's done a lot of things right to gain the reach that it has.

kimmeld 4y ago
Being actively updated and maintained when Perl wasn’t helped Python dramatically.
z9znz 4y ago
> But obviously it's done a lot of things right to gain the reach that it has. Indeed it has. It is a very accessible (and even moreso "available") language. But it has so many odd (and frankly wrong) peculiarities that big projects tend to become more difficult more quickly because of the mess that is most Python code. Some of the footguns are so rediculous that you cannot believe they exist; and even more astounding is the apologist arguments for why they should be the way they are. This one is my favorite: https://stackoverflow.com/questions/1132941/least-astonishment-and-the-mutable-default-argument https://stackoverflow.com/questions/1132941/least-astonishme... Since it is so accessible and has such a rich ecosystem, someone with little skill can cobble together a system which works well enough to get to production. But that junior developer pay rate cost (and ease of hiring) will mean that as the project matures and more and more features are added, the code more rapidly becomes incomprehensible. Everything being mutable, no types (except for bolted on, visually noisy, non-runtime linters), OOP missing some of the key information hiding features, awkward or half-baked functional features, and time/space performance problems all combine to make Python a terrible choice for non-prototype level projects.
- isitmadeofglass 4y ago
  > This one is my favorite: That’s not a confusing language design. It’s a very simple case of mutability that new programmers stumble over because they don’t yet know how to reason about mutability. But go ahead, tell us what should have been done instead here? Make it impossible to pass mutable arguments to functions? Or make it impossible to use mutable variables as default?
  - z9znz 4y ago
    It seems you are misunderstanding something fundamental about this issue. This is not a problem of mutability or immutability of function parameters, but rather that parameter default values are immutable. (But even to your point about making it impossible to pass mutable arguments to functions... that's a very common thing in many languages, even though it is irrelevant to this topic.) This should illustrate the problem: ------------------------------------- Python 3.10.6 (main, Aug 11 2022, 13:36:31) [Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def visit_city(city_name, visited=[]): ... visited.append(city_name) ... return visited ... >>> a = visit_city("Boston") >>> a ['Boston'] >>> a = visit_city("New York", a) >>> a ['Boston', 'New York'] >>> b = visit_city("Dallas") >>> b ['Boston', 'New York', 'Dallas'] >>> -------------------------------- Any reasonable developer would expect b to => ['Dallas']. You absolutely would not expect the value of b to have been influenced by previous calls to visit_city(). Python apologists only offer one positive for this: "It is useful for memoization". That is a very edge case use, and it was not the intention when default arguments were implemented. It was an accidental side use of a misfeature.
    - isitmadeofglass 4y ago
      > but rather that parameter default values are immutable. No they are not, I’d offer you an example, but you gave one yourself. Are you confused as to what mutable and immutable means? > You absolutely would not expect the value of b to have been influenced by previous calls to visit_city(). Yes they would. Python is not a functional language. If you have A=[1,2,3] and call A.append(4), what do you expect A to be? Same if you have a function with argument “mylist” and a default set to A, what do you expect to happen to A if you call mylist.append(4) inside that function body on a call that didn’t pass another list? > Python apologists only offer one positive for this: "It is useful for memoization". No, that is not the only use, if you couldn’t pass mutable arguments you would cripple the language. And if you couldn’t pass mutable defaults you’d have an odd inconsistent handling of them.

01100011 4y ago

Funny how two poorly defined languages, JavaScript and Python, seem to be dominating the world lately. It's almost as if people disagree with your assertion.

z9znz 4y ago
Bringing up Javascript really doesn't help your argument as it is pretty universally deemed a "poorly designed language". Many, many people have written about this. Somewhat randomly selected is this: https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f https://medium.com/javascript-non-grata/javascript-is-a-dysf... (and it references more). Later ECMAScript editions have made good improvements, but there are still plenty of sharp edges and footguns in Javascript which simply do not need to exist. Javascript is a leading language because _practically_ speaking (not strictly speaking) it is the only language you can use if you want to make things happen in the browser. And it came with every major web browser since the late 90s. THAT is why it gained immense marketshare. Python has been included in Linux, *BSD, and macOS for years. It's a very simple language to make things happen with little effort; it is "accessible" to most people, particularly non computer scientists. It reads a little bit more like English than other languages, and it doesn't require compiling (again to accessibility). All these things don't mean it's good. But it got picked up by non-developers and used to solve real world problems and a lot of research problems. More and more specialized modules were written for it, making it even easier to solve many problems. So its accessibility and ecosystem have been good. But that doesn't mean it's good for building big, long lived, easily maintainable or extensible systems. It certainly doesn't mean it's good for building performant systems. See elsewhere in this thread for my link to my biggest complaints (from an old discussion). I'm not a recognized expert on language design, but I've written significant quantities of production code in several languages, including Python, over many years. No doubt people may disagree with my assertion, but using popularity as evidence of disagreement is not valid since popularity often does not correlate to the quality or suitability of something. History is full of companies, technologies, and practices where the most popular was absolutely not the best.
xdfgh1112 4y ago
PHP was one of the most popular languages of the 2000s and was infamously badly designed.

kjeetgill 4y ago

> Python is a very poorly designed language, If you're going to throw around your words so sloppily like this at least give us a few decisions you don't like so we have something real to agree or disagree about, lol

z9znz 4y ago
I've covered this in detail before, so I didn't feel like rehashing it. Also, while in fact I did have a run-on sentence (because I failed to use a semicolon in one place where I used a comma), I don't believe it's reasonable to say my words were sloppy. See this thread if you want more than a few examples of how Python is poorly designed (as compared to Ruby): https://news.ycombinator.com/item?id=32116957 https://news.ycombinator.com/item?id=32116957
IshKebab 4y ago
I don't think it's really a controversial opinion though (except among Python fans, of which there are many due to how popular a teaching language it is). IMO the biggest issue is that they add features with absolutely no regard to how you could implement it with good performance. There are also a ton of features that let you do things that are just a really bad idea. Look at something like __subclasses__. Encourages terrible coding practices! (I learnt about it by reading some terrible code my colleagues wrote.) And good luck JITing that. There's also a ton of syntax that is weird and asymmetric, like list comprehensions. Also the fact that you don't need to explicitly create variables is very error prone. Some of that is excusable given how old Python is but that doesn't mean it isn't bad. Oh and import resolution. That's just downright terrible. No excuse there. I'd almost take #include over the insane mishmash of different ways imports work. It's even worse than JavaScript's module disaster.

skywhopper 4y ago

Yeah, the rationale behind many bizarre decisions always seemed to be “because this is the obvious right way”. Or “because Python favors clarity over magic”. And I’m just “how does that explain why len() is a root namespace method that takes a string arg, while isupper() is a method on string objects?”

im3w1l 4y ago
isupper makes sense only for strings, thus it makes sense not to put it in the global namespace. len is available for strings, but also lists, dicts and many other things. It's so useful that a 3-letter name in the global namespace is justified. Is there a reason for not making it a method though? Yes, actually. By using the dunder system, it makes len special. And it avoids a situation where some objects use a.len() others use b.length() and yet others use c.size() or d.len, e.length, f.size. Python has officially blessed the len name over the others, and that's useful.
- z9znz 4y ago
  That defense doesn't really hold up. len() makes no sense for numbers, booleans, None, and probably other types I cannot think of at the moment. Python has a LONG list of built in functions, most of which are only applicable to a few types of parameters. They could just as well be object methods. https://docs.python.org/3/library/functions.html https://docs.python.org/3/library/functions.html Some of those methods, like sorted(), are terrible names. A past tense verb name... so instead of telling Python, "Hey, please sort() this", you say "Please give me a sorted() thing". So you have the collection.sort() method or the built in sorted() method. They both sort, but they have different options; and significantly, sort() mutates the collection, whereas sorted() returns a new collection. This is inconsistent and creates unnecessary cognitive load. It's another example of a Frankenstein language.
bb88 4y ago
This isn't magic at all. There is a method on all objects which are a collection: __len__() You can try it out yourself. x = [1,2,3,4] print(x.__len__()) #4 y = "abcdefg" print(y.__len__()) #7 z = { "a": "b", "c": "d"} print(z.__len__()) #2 len() is just syntactic sugar for calling __len__(). The "dunder" methods in python are a standard way of extending classes.