Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Python Programming

Python 3.8 Will Finally Include the Walrus Operator (lwn.net) 151

Posted by EditorDavid from the I-am-the-walrus-operator dept.
An anonymous reader quotes LWN: Python 3.8 is feature complete at this point, which makes it a good time to see what will be part of it when the final release is made. That is currently scheduled for October, so users don't have that long to wait to start using those new features.

The headline feature for Python 3.8 is also its most contentious. The process for deciding on Python Enhancement Proposal (PEP) 572 ("Assignment Expressions") was a rather bumpy ride that eventually resulted in a new governance model for the language. That model meant that a new steering council would replace longtime benevolent dictator for life (BDFL) Guido van Rossum for decision-making, after Van Rossum stepped down in part due to the "PEP 572 mess".

Out of that came a new operator, however, that is often called the "walrus operator" due to its visual appearance. Using ":=" in an if or while statement allows assigning a value to a variable while testing it... It is a feature that many other languages have, but Python has, of course, gone without it for nearly 30 years at this point. In the end, it is actually a fairly small change for all of the uproar it caused.
This discussion has been archived. No new comments can be posted.

Python 3.8 Will Finally Include the Walrus Operator More

Python 3.8 Will Finally Include the Walrus Operator

Comments Filter:

  • Glad to hear (Score:5, Funny)

    by nospam007 ( 722110 ) * on Saturday July 20, 2019 @11:36AM (#58956378)

    I am he as you are he as you are me
    And we are all together
    See how they run like pigs from a gun
    See how they fly
    I'm crying

    Sitting on a cornflake
    Waiting for the van to come
    Corporation T-shirt, stupid bloody Tuesday
    Man you've been a naughty boy
    You let your face grow long

    I am the egg man
    They are the egg men
    I am the walrus
    Goo goo g'joo

  • Walrus rules (Score:1)

    by Anonymous Coward

    Can there be a triple or double walrus? When will this be an emoji?

  • Took me a while as well (Score:5, Interesting)

    by Dutch Gun ( 899105 ) on Saturday July 20, 2019 @12:10PM (#58956456)

    So I guess Python now has the equivalent of this in C++:

    if (auto foo = maybeCreateFoo()) {
            foo->doSomething();
    }

    It took me quite a while to warm up to this style of code. I tended to dislike it because I felt the null check was less obvious, and it looks really close to an assignment-instead-of-comparison mistake. I'm a proponent of making my code look stupidly clear and obvious whenever possible, even if it's a bit more verbose, as I think that helps maintainers in the future, even if that maintainer is future me. I finally relented a bit when I realized it at least had a somewhat practical effect beyond conciseness - that of limiting the scope of the variable being created and tested to the if-else block.

    Honestly, I'm not really sure this fits all that well in a language like Python, who's claim to fame is largely about it's accessibility and general ease of use. I've used a bit of Python, but not enough to really offer an expert opinion. Curious to hear what those who use the language a lot more than me feel about it.

    • Re: (Score:2)

      by Viol8 ( 599362 )

      C++ variable declaration in if is broken.

      if (auto foo = ... ) compiles.
      if ((auto foo = ...)) doesn't.

      Which is idiotic since the proper way to test for a non zero assignment value in both C and C++ requires the double brackets and many compilers will complain if you don't to it. Except in this case. Go figure.

      • Re: (Score:2)

        by lgw ( 121541 )

        requires the double brackets

        There were no brackets in your sample. Perhaps you meant parentheses? Brackets, braces, and parentheses are each different characters. Best to keep them straight. Well, appropriately bent.

    • Re:Took me a while as well (Score:5, Insightful)

      by ceoyoyo ( 59147 ) on Saturday July 20, 2019 @12:29PM (#58956496)

      Python might be billed as an easy to use language, but it's got lots of advanced features that can make the newbies' heads spin.

      I don't like this kind of operator though, in whatever language. Operators that do multiple things are bad, and the kind of conciseness that comes from it just ends up biting you in the ass later on.

      • Actually, the problem is with the = operator. It's the one doing multiple things. In many languages it can be used as a comparator (is n equal to 5?) or for variable modification (set n equal to 5). I first encountered := in Pascal (we just called "set equal" - this was a decade before emoticons became a thing). Its introduction splits up these two functions into two operators.
        • = for when you want to do a value comparison.
        • := for when you want to change the value of a variable.

        About the only thing y

        • Re: (Score:2)

          by ceoyoyo ( 59147 )

          The = operator in Python is a pure assignment operator. == is a comparison operator. It's the same way around as in C, but in C you can commit atrocities like

          if (a = 5)

          That's a syntax error in Python.

          As you say, Python is adding a third operator so you can commit a slightly less atrocious version of the classic C error.

          I prefer := as an assignment operator and = as comparison as well, since I also programmed a lot in Pascal, and it's also more consistent with mathematics, but it's just a notational preferen

        • Why does c use == for comparison? It's not consistent with mathematics. It's not consistent with other comparisons - we don't use <<, to mean less than, do we?

      • I don't like this kind of operator though, in whatever language. Operators that do multiple things are bad, and the kind of conciseness that comes from it just ends up biting you in the ass later on.

        That describes just about every syntactic sugar style "innovation" invented for any modern programming language in the last 20 years.

        You can either accept it, and get on with your life, or rage against lighthouses.

    • I'm a proponent of making my code look stupidly clear and obvious whenever possible, even if it's a bit more verbose, as I think that helps maintainers in the future, even if that maintainer is future me. I finally relented a bit when I realized it at least had a somewhat practical effect beyond conciseness - that of limiting the scope of the variable being created and tested to the if-else block.

      I like code that’s stupidly clear, period. There’s not much I dislike more than trying to tease apart someone else’s obscured code logic, especially if it’s in a language I’m not strong in. Brevity only matters if it aids clarity.

      I feel like limiting scope should be stupidly clear and easy to do as well. Perl certainly does this, which could be considered somewhat ironic given how some people view Perl (and some BOFHs write it).

    • Re: (Score:2)

      by jythie ( 914043 )
      The downside here is though, well, python scoping rules are VERY loose, so the advantages of scoping it inside the conditional don't happen.

    • who's claim to fame is largely about it's accessibility

      I don't know. Who is claim to fame? And what has accessibility?

      • "Who's" in this case would be "who has." "Who has claim to fame is..." makes perfect sense.

        And it is fame that has to accessible. To the claimant.

    • Yeah, I don't know C++, and I can't quite tell what that does or why you would do it that way. I'd be interested in an explanation, but I think I understand why you don't like it. I assume it's not just an if/then statement checking if "foo" equals the result of "maybeCreateFoo()".

      I'm kind of not a fan of overly clever programming. I get it when programmers come up with something really elegant and clever, and they're proud of it. I also understand that sometimes it might be important to do something i

      • It's essentially an assignment of a value to foo, then an implicit check to see if foo is not a null pointer, equivalent to this:


        auto foo = maybeCreateFoo();
        if (foo != nullptr) {
        foo->doSomething();
        }

        The only difference is that in the previous example, assuming this is modern C++ and we're retrieving a smart pointer, the object in the first example will be destroyed at the end of the if-block, where in this example, it will only be destroyed at the end of whatever function this

    • Re: (Score:2)

      by CODiNE ( 27417 )

      Usually you can put the constant value or function on the left preventing any accidental assignments.

      This is why occasionally you'll see code like
      if (5==whatever)
      as the compiler throws an error when you forget an equals sign. It won't work in every language but it's an idiom I picked up from C.

  • ... with little scope for confusion. As an occasionally Python programmer (C++ is the day job) I can't see the problem but perhaps more experienced python devs could explain why there was such uproar?

    • Re:Seems like a good idea to me... (Score:4, Interesting)

      by K. S. Kyosuke ( 729550 ) on Saturday July 20, 2019 @12:32PM (#58956508)
      I see quite a lot of opportunity for confusion, given how it completely inverts the Wirthian language conventions where = is an expression construct and := is a statement construct. Now in Python := is an expression and = is a statement construct? Marvelous.

      • Re: (Score:2)

        by ka9dgx ( 72702 )

        It seems that the Python folks want to be actively hostile to newbies. As a long time Turbo Pascal/Delphi programmer, this is going to make me swear a lot in the future.

        • Re: (Score:3)

          by vadim_t ( 324782 )

          A long time Turbo Pascal user is about the furthest thing there is from a newbie.

          I don't think Pascal gets a whole lot of use these days either, at least I've yet to run into a project that uses it.

          • He couldn't possibly mean "a newbie to python" could he, you aspie spaz?

            • Re: (Score:2)

              by vadim_t ( 324782 )

              If you've been coding for 20-30 years, surely a minor syntax thing that's completely optional for you to use, and which is probably not going to get major usage for a while (since it won't be recognized by previous versions) isn't a major hurdle. If you're learning Python, you kind of have to make peace with its way of doing things, such as the indentation, anyway.

              If you're a newbie at programming today, chances are good you've never learned Pascal, and there's not much point doing it anymore.

      • Re: (Score:2)

        by lgw ( 121541 )

        I see quite a lot of opportunity for confusion, given how it completely inverts the Wirthian language conventions

        No one has used Pascal in 30 years, other than APK.

        No one remembers Pascal syntax. It is very dead. And not in the least missed.

      • If you can't handle that level of "complexity" you should probably find a profession you have a chance at being successful in. Software isn't your thing I'm afraid.

    • Re: (Score:3)

      by Joviex ( 976416 )

      ... with little scope for confusion. As an occasionally Python programmer (C++ is the day job) I can't see the problem but perhaps more experienced python devs could explain why there was such uproar?

      Easy -- There are old, get off my lawn, coders.

      Been SWE for 25 years, I see zero problem with this use-case.

      The ones who do, are just old farts who dont like change.

    • Re: (Score:2)

      by steveha ( 103154 )

      As an occasionally Python programmer (C++ is the day job) I can't see the problem but perhaps more experienced python devs could explain why there was such uproar?

      There is a set of rules that are called "The Zen of Python" and most Python people like them. One of the rules is: "There should be one, and preferably only one, obvious way to do anything." Another rule is "Explicit is better than implicit."

      The fact that = doesn't work in an expression meant that everyone had to use an extra statement to modif

  • Lack of a Feature = Feature (Score:2, Insightful)

    by Anonymous Coward

    As a Java developer, I consider the lack of a feature to be a feature... Talented developers know when to avoid hard-to-read language features, but amateurs/juniors/interns don't and they often discover by doing the mistake many many times. Sure, you can use tools such as Sonar to avoid bad practices, but why allowing such bad practice in the first place.

    I can imagine spending hours reading following code and realize that someone a variable in the elseif

    if (condition)
    doThisl
    else if (va

    • Re: (Score:2)

      by efitton ( 144228 )

      It is intended to avoid the loop and a half.

          line = f.readline()
          while line: ... # process line
                  line = f.readline()

      vs:

      while line := f.readline() ... # process line

      The example you stated will remain how that logic flow will work.

    • Re: (Score:2)

      by lgw ( 121541 )

      That's why it's ":=" and not "=". ":=" is used nowhere else in Python, and is a particularly unlikely typo.

  • Given that "=" was already does assignment, why not use that instead?

    Based on a quick glance, it seems the only diference between "=" and ":=" is that the latter is somehow able to be used anywhere, while the former has to be used in a more rigid fashion. It's simpler to just use the same token for both instances and be done with it.

    • Funnily the fortune of the day at the bottom of the page, separated by one post from yours, is:

      Simplicity does not precede complexity, but follows it.

    • Re: (Score:2)

      by jythie ( 914043 )
      That was my initial thought, since 'until you know better', that is the expected behavior of '=' in a conditional anyway.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      It's simpler to just use the same token for both instances and be done with it.

      ... so simple, in fact, that people would end up doing so when they didn't intend to, and the new Python interpreter wouldn't be able to flag the error for them, since the syntax would be legal. Result: lots expensive errors that have to be tracked down at runtime, rather than caught up-front; no bueno.

  • If your walrus face looks like := take him to the vet immediately.

  • This "Walrus Operator" has caused such a fuss, but the sad part is that it's overshadowing what will truly be 3.8's killer feature,
    : multiprocessing.shared_memory https://docs.python.org/3/libr... [python.org]

    • Shared memory in a high-level language is a bit useless since you need to marshall everything to bytes to put them into shared memory.

  • Python has so many poor design choices, it does not surprise me that not contains another incredibly poor one.

    Classic syntax from dozens of other language is that

    if ":=" exists, then it is the standard assignment operator, and "=" is the equality testing operator.

    If ":=" does not exist, then "=" is assignment, and, optionally "==" is equality, otherwise "=" is also equality as defined by syntax. And then, my favorite such operator, in some cases "===" equality tests for the same object, not just the same va

    • Re: (Score:2)

      by caseih ( 160668 )

      You've got that backwards. Who cares what Pascal did. Python certainly doesn't want to make the same mistake that C did by using the = operator as an assignment expression operator. So if you're going to have an assignment operator that works in expressions, it really should be something that you can't accidentally type while trying to do an equality expression. Using a = in an expression in Python is a syntax error. Wish that it were in C and all languages that borrowed the syntax.

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close