7 ms·

O boy, angry rant incoming. I'll say something petulant and overly dramatic, but I don't like the direction in which python is going, and I'm glad there's final

O boy, angry rant incoming. I'll say something petulant and overly dramatic, but I don't like the direction in which python is going, and I'm glad there's finally some news about focus on actual innovation instead of tacking on syntactic cruft. I want the python that Guido promised me, with 2021 performance. I don't want some abhorrent committee-designed piece of middle-of-the-road shitware glue language that I must use because everyone uses it. I want a language that doesn't spin it's single-threaded wheel in a sea of CPU cores, and I want a language that has one obvious way of doing things without needing to grok and parse dumb """clever""" hacks that will only be abused by midlevel programmers to show off hoe they saved typing a few lines of additional code. To me, speed + simplicity = ergonomy = joy. I want a new python 4 to focus exclusively and intensely on performance improvements and ergonomy.

DangitBobby 5y ago
What recent changes to the language do you specifically dislike?
- dataflow 5y ago
  Not the parent but := assignment expressions and match expressions are abominations.
  - asah 5y ago
    Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. They're not niche and "should have" been added years ago. If anything, I'm thrilled with the work of the "committee," whose judgments are better than the result of any individual. Postgres is the same. Gone are the days when you invest in a platform like python, and they make crazy decisions that kill the platform's future (e.g. perl5). Ignore small syntax stuff like := and focus on the big stuff.
    - dataflow 5y ago
      > Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. That says nothing about their quality. It just says you like them. If you gave me unhealthy food I'd probably eat it immediately too. Doesn't mean I think it's good for me. > Ignore small syntax stuff like := and focus on the big stuff. They're not "small" when you immediately start using them in a "large fraction of your code". And a simple syntax that's easy to understand is practically Python's raison d'être. They added constructs with some pretty darn unexpected meanings into what was supposed to be an accessible language, and you want people to ignore them? I would ignore them in a language like C++ (heck, I would ignore syntax complications in C++ to a large degree), but ignoring features that make Python harder to read? To me that's like putting performance-killing features in C++ and asking people to ignore them. It's not that I can't ignore them—it's that that's not the point.
      - DangitBobby 5y ago
        I simply do not understand how the walrus operator is harder to read. Maybe an example? my_match = regex.match(foo) if my_match: return my_match.groups() # continues with the now useless my_match in scope Versus if my_match := regex.match(foo): return my_match.groups() # continues without useless my_match in scope How is the second one less readable? Have you ever heard of a real world example of a beginner or literally anyone ever actually expressing confusion over this?
        dataflow 5y ago
        The problem isn't that simple use case. Although even in that case, they already had '=' as an assignment operator, and they could've easily kept it like the majority of other languages do instead of introducing an inconsistency. The more major problem with the walrus operator is more complicated expressions they made legal with it. Like, could you explain to me why making these legal was a good thing? def foo() return ... def bar(): yield ... while foo() or (w := bar()) < 10: # w is in-scope here, but possibly nonexistent! # Even in C++ it would at least *exist*! print(w) # The variable is still in-scope here, and still *nonexistent* # Ditto as above, but even worse outside the loop print(w := w + 1) If they just wanted your use case, they could've made only expressions of the form 'if var := val' legal, and maybe the same with 'while', not full-blown assignments in arbitrary expressions, which they had (very wisely) prohibited for decades for the sake of readability. And they would've scoped the variable to the 'if', not made it accessible after the conditional. But nope, they went ahead and just did what '=' does in any language, and to add insult to injury, they didn't even keep the existing syntax when it has exactly the same meaning. And it's not like they even added += and -= and all those along with it (or +:= and -:= because apparently that's their taste) to make it more useful in that direction, if they really felt in-expression assignments were useful, so it's not like you get those benefits either.
  - DangitBobby 5y ago
    I have now heard specific concerns with := that make sense to me, but what about match expressions? What about them do you not like?
    - dataflow 5y ago
      What's the output of this program? class C(object): A = 1 B = 2 x = 3 y = 10 print(x - B) match y: case C.A: print('A') case B: print(y - B)
      - DangitBobby 5y ago
        Do you not like the idea of pattern matching as a feature or do you not like the implementation details? This kind of seems like another clumsy scoping problem, no?
        dataflow 5y ago
        I would love a good pattern matching feature, but this is not it. And this is a seriously broken design at a fundamental level, not an "implementation detail". I actually have no clue how it's implemented and couldn't care less honestly. I just know it's incredibly dangerous for the user to actually use, and incredibly unintuitive on its face. It's as front-and-center as a design decision could possibly be, I think. And no, this is not really a scoping issue. Match is literally writing to a variable in one pattern but not the other. A conditional write is just a plain inconsistency. The sad part is both of these features are stumbling over the fact that Python doesn't have variable declarations/initialization. If they'd only introduced a different syntax for initializations, both of these could have been much clearer.
        DangitBobby 5y ago
        > I actually have no clue how it's implemented and couldn't care less honestly. I guess I'm not sure where "design" ends and "implementation" begins? To me, how to handle matching on variables that already exists is both, because "pattern matching and destructuring" are the features and how that must work in the context of the actual language is "implementation". It being written in a design doc and having real world consequences in the resulting code doesn't make it not part of the implementation. Instead of quibbling over terms, I was much more interested in whether you like the idea of pattern matching. I think not liking the final form a feature takes in the language is fundamentally different from wholesale disliking the direction the language design is going.
  - DangitBobby 5y ago
    I'll point out that the walrus operator was actually accepted while Guido was still BDFL (and the vitriol surrounding the decision to include it led directly to him stepping down from the position [1]), so even accepting the fact that it's a poor addition to the language, does not provide support for the statement that "design by committee" has lead to poor language design decisions. 1. https://pythonsimplified.com/the-most-controversial-python-walrus-operator/ https://pythonsimplified.com/the-most-controversial-python-w...
    - dataflow 5y ago
      You'll want to post that as a reply to the parent you originally replied to, since I'm not the one who said anything about design-by-committee.
      - DangitBobby 5y ago
        They gave no specific criticisms. This thread was born of a request for specific criticisms. When that happens, I try to operate as though the assumptions laid out in the parents hold for the children. I think this makes sense to do, especially when you appeared to step in as a proxy expanding on the parent's opinion. Even if that wasn't your intention, this is a public thread, and the most relevant place to post things as a response to a sentiment in a thread may not be directly to a person who holds that exact sentiment. If you don't take issue with "design by committee" then you need not be concerned. I don't think you think that, and I think no less of you regardless.
        dataflow 5y ago
        I meant it moreso that the person whom the reply is actually relevant to might not see it otherwise, but whatever, it's fine with me.
- isoprophlex 5y ago
  The walrus operator is a tired old trope to hate on, but I dont see the point personally. Same goes for the structural pattern matching thing. The tacking on of typing features feels superfluous in a language thats not compiled or even strongly typed. But for the sake of maximum pendatry let me paste some nitpicky little detail from a somewhat recent syntactic addition: >>> def f(a, b, /, **kwargs): ... print(a, b, kwargs) ... >>> f(10, 20, a=1, b=2, c=3) 10 20 {'a': 1, 'b': 2, 'c': 3} a and b are used in two ways. Since the parameters to the left of / are not exposed as possible keywords, the parameters names remain available for use in **kwargs Jesus fucking hell on a tricylce so now i have *'s and /'s showing up in function signatures so someone can prematurely optimize the re-use of variable names without breaking backwards comparability?! Python is becoming a mockery, dying a death through a thousand little cuts to its ergonomics.
  - wenc 5y ago
    > The tacking on of typing features feels superfluous in a language thats not compiled or even strongly typed. Python has always been strongly typed (Python has strong dynamic typing). Adding typechecks moves it towards being gradually/statically-typed.
  - dragonwriter 5y ago
    AFAIK, the purpose of “/” is so that python-implemented functions can be fully signature-(and, therefore, also type-)compatible with builtins and C-implemented functions that required positional arguments but do not accept those arguments being passed as keyword arguments.
  - ptx 5y ago
    I'm sure you're already aware of this example since it's the canonical one, but to me personally the point is very clear: I use regular expressions all the time and always have to write that little bit of boilerplate, which the walrus operator now lets me get rid of. Avoiding tedious boilerplate by adding nice features like the walrus operator is precisely what lets us avoid "death through a thousand little cuts to its ergonomics", in my view. Sure, maybe writing m = re.match("^foo", s) if m != None: ... isn't so bad, but in that case maybe writing i = 0 while i < len(stuff): element = stuff[i] ... i += 1 wouldn't be so bad, and we could get rid of Python's iterator protocol?
- ahmedfromtunis 5y ago
  Not the OP but some of the late additions to Python were, *in MY very humble opinion* not very pythonic; just a syntactic sugar that meant there are now more than just one way of doing things. On that list: the walrus operator and the new switch thing. If I understand them fully and correctly, those two things don't enable developers to do things that were impossible before, instead they add new ways to do things that were possible prior. That's the Python I know and love. Of course, this doesn't mean I'll love Python any less, just that I wished there were more focus on staff that matters like the topic of this article. Or maybe getting type hinting better. Again, this is just my opinion.
  - DangitBobby 5y ago
    IMO, the "one obvious way to do things" has always been a comforting fiction. There are numerous ways to do everything, the worst offenders forcing people to make tradeoffs between debuggability and readability (ie, for loops versus list comprehensions). Many of them are purely about readability (ternary expression versus if blocks) and many of them are about style (ternary expression versus use of or/and short-circuiting). Even so, before the walrus operator, there was never a way to define a variable that only existed in the scope of a particular if statement. After using pattern matching in Rust and switch statements in JavaScript, I personally am very excited for that addition to Python, but I understand the feature is divisive and will concede it as a matter of opinion. Edit: turns out the walrus operator does not cause the variable to move out of scope after the if block, which is disappointing. IMO the worse anti-pattern has already been part of the language, which is not creating new scopes for if statements.
  - xorcist 5y ago
    The "one thing to do it" was never to be taken literally, it was mostly to mock Perl programmers. Python always had at least half a dozen ways of doing trivial things such as packaging dependencies or even doing http requests or looping over stuff.
  - slightwinder 5y ago
    Half of python was always syntactic sugar that could be also done one way or another with more primitive code. I mean for-loops, elif, import, the whole OOP; all just redundant syntactic sugar. Pythonic never meant to make the syntax less "sweet". Python is about making simple, straight forward code which removes unnecessary friction. And that's exactly what the walrus and switch are doing on their own. But yes, of course can one also argue that they add friction on the global scale, because it's yet another syntax-element to know about, and the benefit is rather small on surface. But that's the problem with syntax, it's always a trade-off between overhead and benefit.

DangitBobby 5y ago

What recent changes to the language do you specifically dislike?

dataflow 5y ago
Not the parent but := assignment expressions and match expressions are abominations.
- asah 5y ago
  Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. They're not niche and "should have" been added years ago. If anything, I'm thrilled with the work of the "committee," whose judgments are better than the result of any individual. Postgres is the same. Gone are the days when you invest in a platform like python, and they make crazy decisions that kill the platform's future (e.g. perl5). Ignore small syntax stuff like := and focus on the big stuff.
  - dataflow 5y ago
    > Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. That says nothing about their quality. It just says you like them. If you gave me unhealthy food I'd probably eat it immediately too. Doesn't mean I think it's good for me. > Ignore small syntax stuff like := and focus on the big stuff. They're not "small" when you immediately start using them in a "large fraction of your code". And a simple syntax that's easy to understand is practically Python's raison d'être. They added constructs with some pretty darn unexpected meanings into what was supposed to be an accessible language, and you want people to ignore them? I would ignore them in a language like C++ (heck, I would ignore syntax complications in C++ to a large degree), but ignoring features that make Python harder to read? To me that's like putting performance-killing features in C++ and asking people to ignore them. It's not that I can't ignore them—it's that that's not the point.
    - DangitBobby 5y ago
      I simply do not understand how the walrus operator is harder to read. Maybe an example? my_match = regex.match(foo) if my_match: return my_match.groups() # continues with the now useless my_match in scope Versus if my_match := regex.match(foo): return my_match.groups() # continues without useless my_match in scope How is the second one less readable? Have you ever heard of a real world example of a beginner or literally anyone ever actually expressing confusion over this?
      - dataflow 5y ago
        The problem isn't that simple use case. Although even in that case, they already had '=' as an assignment operator, and they could've easily kept it like the majority of other languages do instead of introducing an inconsistency. The more major problem with the walrus operator is more complicated expressions they made legal with it. Like, could you explain to me why making these legal was a good thing? def foo() return ... def bar(): yield ... while foo() or (w := bar()) < 10: # w is in-scope here, but possibly nonexistent! # Even in C++ it would at least *exist*! print(w) # The variable is still in-scope here, and still *nonexistent* # Ditto as above, but even worse outside the loop print(w := w + 1) If they just wanted your use case, they could've made only expressions of the form 'if var := val' legal, and maybe the same with 'while', not full-blown assignments in arbitrary expressions, which they had (very wisely) prohibited for decades for the sake of readability. And they would've scoped the variable to the 'if', not made it accessible after the conditional. But nope, they went ahead and just did what '=' does in any language, and to add insult to injury, they didn't even keep the existing syntax when it has exactly the same meaning. And it's not like they even added += and -= and all those along with it (or +:= and -:= because apparently that's their taste) to make it more useful in that direction, if they really felt in-expression assignments were useful, so it's not like you get those benefits either.
- DangitBobby 5y ago
  I have now heard specific concerns with := that make sense to me, but what about match expressions? What about them do you not like?
  - dataflow 5y ago
    What's the output of this program? class C(object): A = 1 B = 2 x = 3 y = 10 print(x - B) match y: case C.A: print('A') case B: print(y - B)
    - DangitBobby 5y ago
      Do you not like the idea of pattern matching as a feature or do you not like the implementation details? This kind of seems like another clumsy scoping problem, no?
      - dataflow 5y ago
        I would love a good pattern matching feature, but this is not it. And this is a seriously broken design at a fundamental level, not an "implementation detail". I actually have no clue how it's implemented and couldn't care less honestly. I just know it's incredibly dangerous for the user to actually use, and incredibly unintuitive on its face. It's as front-and-center as a design decision could possibly be, I think. And no, this is not really a scoping issue. Match is literally writing to a variable in one pattern but not the other. A conditional write is just a plain inconsistency. The sad part is both of these features are stumbling over the fact that Python doesn't have variable declarations/initialization. If they'd only introduced a different syntax for initializations, both of these could have been much clearer.
        DangitBobby 5y ago
        > I actually have no clue how it's implemented and couldn't care less honestly. I guess I'm not sure where "design" ends and "implementation" begins? To me, how to handle matching on variables that already exists is both, because "pattern matching and destructuring" are the features and how that must work in the context of the actual language is "implementation". It being written in a design doc and having real world consequences in the resulting code doesn't make it not part of the implementation. Instead of quibbling over terms, I was much more interested in whether you like the idea of pattern matching. I think not liking the final form a feature takes in the language is fundamentally different from wholesale disliking the direction the language design is going.
- DangitBobby 5y ago
  I'll point out that the walrus operator was actually accepted while Guido was still BDFL (and the vitriol surrounding the decision to include it led directly to him stepping down from the position [1]), so even accepting the fact that it's a poor addition to the language, does not provide support for the statement that "design by committee" has lead to poor language design decisions. 1. https://pythonsimplified.com/the-most-controversial-python-walrus-operator/ https://pythonsimplified.com/the-most-controversial-python-w...
  - dataflow 5y ago
    You'll want to post that as a reply to the parent you originally replied to, since I'm not the one who said anything about design-by-committee.
    - DangitBobby 5y ago
      They gave no specific criticisms. This thread was born of a request for specific criticisms. When that happens, I try to operate as though the assumptions laid out in the parents hold for the children. I think this makes sense to do, especially when you appeared to step in as a proxy expanding on the parent's opinion. Even if that wasn't your intention, this is a public thread, and the most relevant place to post things as a response to a sentiment in a thread may not be directly to a person who holds that exact sentiment. If you don't take issue with "design by committee" then you need not be concerned. I don't think you think that, and I think no less of you regardless.
      - dataflow 5y ago
        I meant it moreso that the person whom the reply is actually relevant to might not see it otherwise, but whatever, it's fine with me.
isoprophlex 5y ago
The walrus operator is a tired old trope to hate on, but I dont see the point personally. Same goes for the structural pattern matching thing. The tacking on of typing features feels superfluous in a language thats not compiled or even strongly typed. But for the sake of maximum pendatry let me paste some nitpicky little detail from a somewhat recent syntactic addition: >>> def f(a, b, /, **kwargs): ... print(a, b, kwargs) ... >>> f(10, 20, a=1, b=2, c=3) 10 20 {'a': 1, 'b': 2, 'c': 3} a and b are used in two ways. Since the parameters to the left of / are not exposed as possible keywords, the parameters names remain available for use in **kwargs Jesus fucking hell on a tricylce so now i have *'s and /'s showing up in function signatures so someone can prematurely optimize the re-use of variable names without breaking backwards comparability?! Python is becoming a mockery, dying a death through a thousand little cuts to its ergonomics.
- wenc 5y ago
  > The tacking on of typing features feels superfluous in a language thats not compiled or even strongly typed. Python has always been strongly typed (Python has strong dynamic typing). Adding typechecks moves it towards being gradually/statically-typed.
- dragonwriter 5y ago
  AFAIK, the purpose of “/” is so that python-implemented functions can be fully signature-(and, therefore, also type-)compatible with builtins and C-implemented functions that required positional arguments but do not accept those arguments being passed as keyword arguments.
- ptx 5y ago
  I'm sure you're already aware of this example since it's the canonical one, but to me personally the point is very clear: I use regular expressions all the time and always have to write that little bit of boilerplate, which the walrus operator now lets me get rid of. Avoiding tedious boilerplate by adding nice features like the walrus operator is precisely what lets us avoid "death through a thousand little cuts to its ergonomics", in my view. Sure, maybe writing m = re.match("^foo", s) if m != None: ... isn't so bad, but in that case maybe writing i = 0 while i < len(stuff): element = stuff[i] ... i += 1 wouldn't be so bad, and we could get rid of Python's iterator protocol?
ahmedfromtunis 5y ago
Not the OP but some of the late additions to Python were, *in MY very humble opinion* not very pythonic; just a syntactic sugar that meant there are now more than just one way of doing things. On that list: the walrus operator and the new switch thing. If I understand them fully and correctly, those two things don't enable developers to do things that were impossible before, instead they add new ways to do things that were possible prior. That's the Python I know and love. Of course, this doesn't mean I'll love Python any less, just that I wished there were more focus on staff that matters like the topic of this article. Or maybe getting type hinting better. Again, this is just my opinion.
- DangitBobby 5y ago
  IMO, the "one obvious way to do things" has always been a comforting fiction. There are numerous ways to do everything, the worst offenders forcing people to make tradeoffs between debuggability and readability (ie, for loops versus list comprehensions). Many of them are purely about readability (ternary expression versus if blocks) and many of them are about style (ternary expression versus use of or/and short-circuiting). Even so, before the walrus operator, there was never a way to define a variable that only existed in the scope of a particular if statement. After using pattern matching in Rust and switch statements in JavaScript, I personally am very excited for that addition to Python, but I understand the feature is divisive and will concede it as a matter of opinion. Edit: turns out the walrus operator does not cause the variable to move out of scope after the if block, which is disappointing. IMO the worse anti-pattern has already been part of the language, which is not creating new scopes for if statements.
- xorcist 5y ago
  The "one thing to do it" was never to be taken literally, it was mostly to mock Perl programmers. Python always had at least half a dozen ways of doing trivial things such as packaging dependencies or even doing http requests or looping over stuff.
- slightwinder 5y ago
  Half of python was always syntactic sugar that could be also done one way or another with more primitive code. I mean for-loops, elif, import, the whole OOP; all just redundant syntactic sugar. Pythonic never meant to make the syntax less "sweet". Python is about making simple, straight forward code which removes unnecessary friction. And that's exactly what the walrus and switch are doing on their own. But yes, of course can one also argue that they add friction on the global scale, because it's yet another syntax-element to know about, and the benefit is rather small on surface. But that's the problem with syntax, it's always a trade-off between overhead and benefit.