6 ms·

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 n

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.
      - z9znz 4y ago

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.
    - z9znz 4y ago