Hacker News Reader

Comment by np_tedious | Hacker News Reader

> These changes are major enough that a fair number of existing Python libraries that work directly with Python’s internals (e.g., Cython) would need to be rewritten. But the cadence of Python’s release schedule just means such breaking changes would need to be made in a major point release instead of a minor one.

Maybe time to rethink? https://www.techrepublic.com/article/programming-languages-w...

If this is as promising as it sounds, it seems Python 4 now has its "thing" and is on the horizon. Or at least may become a serious thing to talk about

View on HN

I began using python during the python3.0 betas, and I watched the 2 vs 3 saga from the (unusual?) perspective of a v3 hobbyist with no back-compat requirements.

What struck me as most significant was the opportunistic breakage of things not related to the unicode transition. In the many years it took to win people over to v3, they could have marched over all the breaking changes a year at a time. Given that side-by-side installs of python3.x point versions are very functional, with or without venvs, this would have been much more palatable. Perhaps harder than it sounds though.

I attempted a couple of 2to3 translations of open source libraries over the years, with varying degrees of success. Every time I found that most of the changes were easy, but debugging the broken bits was hard due to the sheer volume of source changes. If instead I could have done conversions where there was only a single major semantic change at a time, it would be so much easier to figure out what was going wrong at any given step. Furthermore, I imagine that a single-breaking-change mentality would lead to better documentation on how to transition for each version.

For this reason, I have become rather suspicious of yearly release schedules. Swift is even more frustrating: the version changes are really just dictated by Apple's yearly PR calendar. Some big things get rushed out for WWDC before they are ready, and smaller fixes can get held back until the next year. I would much rather that the language teams just prioritize one thing at a time, release it when it is ready, and foster a community where staying up-to-date on the latest version is easy and desirable (a more complicated story for Apple than for Python I think, due to ABI, OS version, etc).

From past discussions on HN I've gathered that there is such a thing as release fatigue, where developers get irritated when libraries release breaking changes too often. Nevertheless I often wonder if languages and libraries could improve faster by making more breaking changes, one at a time, with robust side-by-side installs to facilitate testing across versions. I wish side-by-side library versions were possible in Python, just to facilitate regression testing.

Bringing this all back to the post, I sincerely hope that if Python 4 is a breaking change to the GIL, that it will be only that.

I'm curious what others think about all this. Thoughts?

> If instead I could have done conversions where there was only a single major semantic change at a time,

That was the point of the "from __future__" imports. You could get most of the way toward Python 3 so that 2to3 would be easier to work with and the new semantics could be gradually baked into the code prior to migration.

Python 3 had 25 years of cruft to clean up. They won't have to do that again.

If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. People will just be scared of new releases. No one will adopt a new language version as soon as it releases. Java never breaks backwards compatibility and still there are people running Java 8. Imagine what would happen if every point release carries breaking changes. It makes you feel that the language is not mature, the library ecosystem broken, since you'll have to keep track of version compatibility for each library that you use. It's a nightmare for both library developers and end-users. Few people would like to use such a language

> If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases.

This.

It makes absolutely no sense to claim that having to deal with a single non-backwards compatible release is somehow worse than having to deal with a sequence of non-backwards compatible releases.

Even though the migration from Python2 to Python3 faced some resistence, if anything the decision was totally vindicated.

I thought the use case mentioned made sense, that of essentially being able to perform patches in a series, as opposed to trying to fix many breaking changes at once. You know. Iterative development. I think 'makes absolutely no sense' is a little harsh.

Idealists and free developers (who have created the majority of the Python interpreter) agree with you.

Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot.

Corporations might even take over more C extensions whose developers are no longer willing to put up with the churn and who have moved to C++ or Java.

In the long run, this is bad for Python. But many developers want to milk the snake until their retirement and don't care what happens afterwards.

"Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot."

In my 20+ year career I have never worked with a programmer that matches this description.

Maybe I've got lucky.

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.

What recent changes to the language do you specifically dislike?

Not the parent but := assignment expressions and match expressions are abominations.

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.

> 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.

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?

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.

In your example, if you leave out the parentheses around w := bar(), you get "SyntaxError: cannot use assignment expressions with operator" which makes me think it's a bug in the interpreter and not intentionally designed to allow it.

I am baffled to learn that it's kept in scope outside of the statement it's assigned, and I agree it would have a negative impact on readability if used outside of the if statement.

> if you leave out the parentheses around w := bar(), you get "SyntaxError: cannot use assignment expressions with operator" which makes me think it's a bug in the interpreter and not intentionally designed to allow it.

No, I'm pretty sure that's intentional. You want the left-hand side of an assignment to be crystal clear, which "foo() or w := bar()" is not. It looks like it's assigning to (foo() or w).

To be clear:

    def thing(): return True
    
    if thing() or w:= "ok": # SyntaxError: cannot use assignment expressions with operator
        pass
    print(w)

    . . .

    if thing() or (w := "ok"):
        pass
    print(w) # NameError: name 'w' is not defined

The first error makes me think your concern (that w is conditionally undefined) was anticipated and supposed to be guarded against with the SyntaxError. I believe the fact you can bypass it with parentheses is a bug and not an intentional design decision.

Oh I see, you're looking at it from that angle. But no, it's intentional. Check out PEP 572 [1]:

> The motivation for this special case is twofold. First, it allows us to conveniently capture a "witness" for an any() expression, or a counterexample for all(), for example:

  if any((comment := line).startswith('#') for line in lines):
    print("First comment:", comment)
  else:
    print("There are no comments")

I have a hard time believing even the authors (let alone you) could tell me with a straight face that that's easy to read. If they really believe that, I... have questions about their experiences.

The beauty of Python...

[1] https://www.python.org/dev/peps/pep-0572/

Your new example makes me wonder: if I can intentionally conditionally bring variables into existence with the walrus operator, what's the motivation behind the SyntaxError in my statement above? I maintain my belief that the real issue here is, readability aside, if blocks do not implement a new scope, which has always been a problem in the language. The walrus operator just gives you new ways to trip over that problem.

From the PEP:

> An assignment expression does not introduce a new scope. In most cases the scope in which the target will be bound is self-explanatory: it is the current scope. If this scope contains a nonlocal or global declaration for the target, the assignment expression honors that. A lambda (being an explicit, if anonymous, function definition) counts as a scope for this purpose.

I find this particularly strange and inconsistent:

    lines = ["1"]

    [(comment := line).startswith('#') for line in lines]

    print(comment) # 1

    [x for x in range(3)]
    print(x) # NameError: name 'x' is not defined

> what's the motivation behind the SyntaxError in my statement above?

I'm pretty sure it's what I explained here: https://news.ycombinator.com/item?id=28899404

I did not understand what you meant.

I'm saying it's the same reason why (x + y = z) should be illegal even if (x + (y = z)) is legal in any language. It's not specific to Python by any means. The target of an assignment needs to be obvious and not confusing. You don't want x + y to look like it's being assigned to.

I see. It has low precedence in the operator hierarchy [1] so

    False or w := 1:

Is grouped like so:

    (False or w) := 1

Which is a SyntaxError. That's... not a smart place for it to be in the operator hierarchy. I expected it to be near the very top, like await.

1. https://docs.python.org/3/reference/expressions.html#operato...

Edit: 20 minutes later, can't respond.

There are two aspects I have been thinking about while looking at this: Introduction of non-obvious behavior (foot-guns) and readability. Readability is important, but I have been thinking primarily about the foot-gun bits, and you have been emphasizing the readability bits. I can't really accurately assess readability of something until I encounter it in the wild.

If the precedence was higher then you'd get a situation like

  x := 1 if cond else 2

never resulting in x := 2 which is pretty unintuitive.

And you have to realize, even if the precedence works out, nobody is going to remember the full ordering for every language they use. People mostly remember a partial order that they're comfortable with, and the rest they either avoid or look up as needed. Like in C++, I couldn't tell you exactly how (a << b = x ? c : d) groups (though I could make an educated guess), and I don't have any interest in remembering it either.

Ultimately, this isn't about the actual precedence. Even if the precedence was magically "right", it's about readability. It's just not readable to assign to a compound expression, even if the language has perfect precedence.

While the walrus operator gives a way to see this sort of non-C++ behavior, it's more showing that Python isn't C++ than something special about the operator.

Here's another way to trigger the same NameError, via "global":

    import random
    def foo():
        return random.randrange(2)
    def bar():
        global w
        w = return random.randrange(20)
        return w
        
    while foo() or (bar() < 10):
        print(w)

For even more Python-is-not-C++-fun:

    import re
    def parse_str(s):
        def m(pattern):  # I <3 Perl!
            nonlocal _
            _ = re.match(pattern, s)
            return _ is not None

        if m("Name: (.*)$"):
            return ("name", _[1])
        if m("State: (..) City: (.*)$"):
            return ("city", (_[2], _[1]))
        if m(r"ZIP: (\d{5})(-(\d{4}))?$"):
            return ("zip", _[1] + (_[2] if _[2] else ""))

        return ("Unknown", s)
        del _  # Remove this line and the function isn't valid Python(!)

    for line in (
            "Name: Ernest Hemingway",
            "State: FL City: Key West",
            "ZIP: 33040",
            ):
        print(parse_str(line))

Right, I'm quite well-aware of that, but I'm saying this change has made the situation even worse. If they ensured the variables were scoped and actually initialized it'd have actually been an improvement.

I apologize. I misinterpreted your comment:

      # w is in-scope here, but possibly nonexistent!
      # Even in C++ it would at least *exist*!

because I don't see how bringing up C++'s semantics is relevant when Python has long raised an UnboundLocalError for similar circumstances.

If I understand you correctly, you believe Python should have introduced scoping so the "w" would be valid only in the if, elif, and else clauses, and not after the 'if' ends.

This would be similar to how the error object works in the 'except' clause:

  >>> try:
  ...   1/0
  ... except Exception as err:
  ...   err = "Hello"
  ...
  >>> err
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'err' is not defined

If so, I do not have the experience or insight to say anything meaningful.

The walrus operator provides no benefit here. `my_match` is still in scope in both cases.

Python’s `if` statements do not introduce a new scope.

I know they don't, normally. I really thought that was basically the point of the walrus operator to begin with, that the variable was only in scope for the lifetime of the if statement where it's needed. Huge bummer to find out that's not true.

Looks like now you're seeing why it's an abomination ;)

IMO the real abomination was already present in the language, which is that if blocks do not introduce new scope. My IDE protects me from the bugs this could easily introduce when I try to use a variable that may not yet be in scope, but it should be detected before runtime.

I will readily admit that the walrus operator doesn't do what I thought it did and I have no interest in whatever utility it provides as it exists today.

> IMO the real abomination was already present in the language, which is that if blocks do not introduce new scope.

Definitely. You would think if they're going to undermine decades of their own philosophy, they would instead introduce variable declarations and actually help mitigate some bugs in the process.

Scoop in python is normally defined by functions/methods, not blocks. The same happens with for-loos and with-blocks. So this is consistent. And this good, because it can be very useful. The exception here are try/except-blocks, where the fetched error is cleaned up after leaving the except-block, for reasons.

There's this example from an explanation linked elsewhere in the discussion. The relevant parts of the if statement are now much further separated.

if (percentage := ((student["marks"]/700)*100)) > 70:

I don't know how important this is, but I believe it does make it less readable for "outsiders".

As a non-Python programmer it is usually pretty easy for me to correctly guess what a piece of Python code does. (And once in a while I need to take a look at some Python code).

Walrus operator got me. I tried to guess what it did, but even having simple code examples I could not. My guesses were along the lines of binding versus plain assignment, or some such. None of my guesses were even close. I had to google it to find out (of course I could also read the documentation).

I have now heard specific concerns with := that make sense to me, but what about match expressions? What about them do you not like?

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)

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?

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.

> 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.

Design is the thing the client sees, implementation is the stuff they don't see. In this case the user is the one using match expressions. And they're seeing variables mutate inconsistently. It's practically impossible for a user not to see this, even if they wanted to. Calling that an implementation detail is like calling your car's steering wheel an implementation detail.

But I mean, you can call it that if you prefer. It's just as terrible and inexcusable regardless of its name. And yes, as I mentioned, I would have loved to have a good pattern matching system, but so far the "direction" they're going is actively damaging the language by introducing more pitfalls instead of fixing the existing ones (scopes, declarations, etc.). Just because pattern matching in the abstract could be a feature, that doesn't mean they're going in a good direction by implementing it in a broken way.

I guess like they say, the road to hell is paved with good intentions.

> Design is the thing the client sees, implementation is the stuff they don't see.

By this definition, bugs and other unintended consequences that the user encounters are "Design".

> Calling that an implementation detail is like calling your car's steering wheel an implementation detail.

Yes, if there weren't so many important decisions behind the outcome of a car being steered with a steering wheel, it could be a steering handle, or a steering joystick, or just about anything else that allows you to orient the front wheels of the car. The same is true of the pedals on the floor. Those could be implemented as controls on the steering wheel instead. Whether it's an implementation detail depends on the specificity of the feature in question. When I asked you about an "implementation detail", it was scoped to "the feature is pattern matching" (can I steer the car?) and you scoped it to "the feature is pattern matching without overwriting variables conditionally in surprising ways" (can I steer the car with failure modes that aren't fatal?).

> Instead of quibbling over terms

and then all that?

Yes, I am definitely now quibbling over terms. I'm not sure what an appropriate response would have been? Just silence? You responded rather uncharitably and I didn't like it. I felt the need to defend my position.

Not silence, just continuing whatever your underlying point was if your goal wasn't to quibble over semantics. Now I have no idea what you're referring to, but this is clearly getting personal, so let's just leave this here. I think at this point we're both clear on the concrete problems with these features and what our positions are.

IMO the match statement has some very unintuitive behaviour:

    match status:
        case 404:
            return "Not found"

    not_found = 404
    match status:
        case not_found:
            return "Not found"

The first checks for equality (`status == 404`) and the second performs an assignment (`not_found = status`).

`not_found` behaving differently from the literal `404` breaks an important principle: “if you see an undocumented constant, you can always name it without changing the code’s meaning” [0].

[0] https://twitter.com/brandon_rhodes/status/136022610839909990...

Aw dang you spoiled it :-) I was hoping my example would be more fun to work through haha.

I see. Is it fair to say your issue with the feature is less about not wanting the feature and more about the implementation details?

Actually, I don’t really want the feature. It’s complicated and it doesn’t really fit with the rest of the language (it breaks fundamental rules, as above, and has scoping issues).

Worst of all, though, it’s really just another way to write if-elif-else chains that call `isinstance` - a pattern which Python traditionally discouraged in favour of duck-typing.

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-w...

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.

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.

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.

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.

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.

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?

It should have been “if … as y” and reused existing syntax. I’ve never seen anyone use the extended variant (multiple assignment) that walrus allows. The extra colons with this and typing makes it look like a standard punctuation-heavy language we sought to avoid in the first place.

I think regex matches might be literally the only use case for := that I come across with any kind of nontrivial frequency, and it's only a minor nuisance at that. Certainly nothing to warrant an entirely new yet different syntax for something we already have.

The iterator protocol is way more general than what you have; it's not remotely comparable.

I've come to like using:

    if foo := data.get("foo"):
        handle_foo(foo)

That’s exactly the same as this, though.

    foo = data.get("foo")
    if foo:
        handle_foo(foo)

The only place I have found the walrus operator useful is in similar `while` loops, where the equivalent code would be:

    while True:
        foo = data.get("foo")
        if not foo: break
        handle_foo(foo)

No it's not the same. The visibility of variable "foo" is extended beyond it's usefullness if you use `if`.

No, the visibility of `foo` is the same in both examples. Python’s `if` statements do not introduce a new scope.

The loop can be written using This One Weird Trick that Walruses Hate:

  for foo in iter(partial(data.get, "foo"), None):
      handle_foo(foo)

So I would only use the walrus operator for the first example (the if statement), which even though it is exactly the same as doing it in two steps just feels nicer as a single step.

Regex is just a prominent example of a certain pattern. Depending on work and style, one often has functions which return something, on which in case of a non-empty result you want to do something more. Walrus can shrink the code in data-intensive code quite well from my experience.

> 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.

Python is strongly typed. Dynamic, but not weak.

Yeah, thanks for the correction. Shows what I know; I'm just a grumpy mediocre programmer whose rants shouldn't be taken too seriously ;)

I find a little irony in the recent additions. A walrus operator sounds very Perl-ish.

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.

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.

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.

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.

I'd wonder if it would be easier to introduce a totally new API along the lines of ruby's ractor API[1] that enables thread parallelism while keeping existing Thread behavior identical as with the GIL. Tons of python code relies on threaded code that is thread-safe under the GIL, but would completely blow up if the GIL was naively replaced.

[1] https://docs.ruby-lang.org/en/master/doc/ractor_md.html

Ractors don't offer very good performance yet. Better to have it be awesome right off the bat

Yeah, That's what I thought. I think the greatest barrier now is that most multithreaded python code right now is just barely thread-safe, even with the GIL. I occasionally have to remind colleagues that even though the GIL guarantees instructions are atomic, you need to use mutexes and other synchronization primitives to ensure there is no race condition between multiple instructions. I'd imagine this change would be an optional interpreter feature initially, since removing the GIL would break the vast majority of code out in the wild, and it would be much more difficult to create an automated conversion tool like they did with the syntactic changes between 2.7 and 3

Cython itself should be a relatively simple fix (relative to the difficulty that Cython devs are accustomed to). Libraries that use Cython in a pure way (that is, not fussing with refcounts in hand-written C code) should "just work" after Cython gets updated. It's the poor folk who have done straight C extensions without the benefit of Cython that I'm concerned about.

A simple solution would be to introduce two new types: ConcurrentThread and ParallelThread. Alias the old Thread to the ConcurrentThread and keep the behaviour. No breaking changes, easy to explain the differrence. People who need it can use the new truly parallel version.

Reply on news.ycombinator.com