Stories
Slash Boxes
Comments

SoylentNews is people

Python's Guido van Rossum Steps Down

posted by martyb on Friday July 13 2018, @12:58PM   Printer-friendly
from the pass-it-on dept.

canopic jug writes:

On a python developers' mailing list for the core developers, Python Committers, Benevolent Dictator for Life Guido van Rossum has announced that he is stepping down effective immediately and with out appointing a successor.

Now that PEP 572 is done, I don't ever want to have to fight so hard for a
PEP and find that so many people despise my decisions.

I would like to remove myself entirely from the decision process. I'll
still be there for a while as an ordinary core dev, and I'll still be
available to mentor people -- possibly more available. But I'm basically
giving myself a permanent vacation from being BDFL, and you all will be on
your own.

After all that's eventually going to happen regardless -- there's still
that bus lurking around the corner, and I'm not getting younger... (I'll
spare you the list of medical issues.)

I am not going to appoint a successor.

[...] I'll still be here, but I'm trying to let you all figure something out for
yourselves. I'm tired, and need a very long break.

Original Submission

 
This discussion has been archived. No new comments can be posted.
Python's Guido van Rossum Steps Down | Log In/Create an Account | Top | 93 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 4, Interesting) by Alfred on Friday July 13 2018, @04:29PM (6 children)

    by Alfred (4006) on Friday July 13 2018, @04:29PM (#706684) Journal
    Damn, what was in PEP 572?
    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   4  

  • (Score: 4, Interesting) by Thexalon on Friday July 13 2018, @05:23PM (5 children)

    by Thexalon (636) on Friday July 13 2018, @05:23PM (#706700)

    You can read PEP 572 [python.org] yourself, but from what I can tell:

    The idea is to define "spam := eggs" to be an operator that behaves like "spam = eggs" does in C, where you can then take the result of the expression and use it in other expressions. For example, this is incorrect Python:

    if (my_file=open("/tmp/some-file", "r"):
        ...
        my_file.close()

    By contrast, this is correct C:

    if (my_file=fopen("/tmp/some-file", "r")) {
        ...
        fclose(my_file);
    }

    Really, I think neither of those are ideal, and this bit of Python is the best way of handling the situation:

    with open("/tmp/some-file", "r") as my_file:
       ...

    The beauty of that is that at the end of the "with" block, the interpreter closes down the file for me and I don't have to worry about forgetting and running out of file handles.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.

    • (Score: 2) by HiThere on Friday July 13 2018, @06:00PM (4 children)

      by HiThere (866) Subscriber Badge on Friday July 13 2018, @06:00PM (#706716) Journal

      For that particular use case, you have an argument. There are many others, however, where assignment to a variable within an expression is beneficial. And there are reasonable arguments that it shouldn't be a simple equal sign, as that increases the number of errors. (Suppose you have a sticky equal sign...extraneous doubles would be uncomfortably frequent, and easy to miss.) Requiring a colon-equal (":=") minimizes the likelihood of this problem. This allows a greater number of errors to be detected during the syntactic pass.

      P.S.: I don't know if those were his arguments. They're the ones that occur to me off the top of my head. I doubt that Pascal usage played any part.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.

      • (Score: 3, Insightful) by Thexalon on Friday July 13 2018, @06:12PM (3 children)

        by Thexalon (636) on Friday July 13 2018, @06:12PM (#706718)

        The other obvious way to handle those situations is to make the assignment and the expression two separate statements, because this really is syntactic sugar we're talking about here.

        In short, this:

        make_breakfast(spam := eggs)

        Versus this:

        spam = eggs
        make_breakfast(spam)

        It is definitely a matter of taste and opinion which one is clearer.

        --
        The only thing that stops a bad guy with a compiler is a good guy with a compiler.

        • (Score: 1, Interesting) by Anonymous Coward on Friday July 13 2018, @07:10PM (2 children)

          by Anonymous Coward on Friday July 13 2018, @07:10PM (#706743)

          That is true, and a large part of the rationale comes from real world examples suggesting people write code that prefers fewer lines even over more efficient alternatives. Things like

          group = re.match(data).group(1) if re.match(data) else None

          or

          match1 = pattern1.match(data)
          match2 = pattern2.match(data)
          if match1:
                  result = match1.group(1)
          elif match2:
                  result = match2.group(2)
          else:
                  result = None

          generally the new syntax allows for code that is both more readable and more compact. (Once familiar with the new := operand) Those exampels come from the pep, there are many more showing clean improvements it enables in the python source code itself.

          • (Score: 1, Interesting) by Anonymous Coward on Friday July 13 2018, @07:25PM (1 child)

            by Anonymous Coward on Friday July 13 2018, @07:25PM (#706748)

            group = re.match(data).group(1) if re.match(data) else None

            They got sick of people monkey patching the standard lib to use an LRU cache on compiled re patterns or complaining about the performance, so they added it themselves. If you are really concerned about performance from standard constructs like that, then either the programmer or core devs could just do it for that one too. It's even in the same module.

            Your second example is much more readable to me using the suggested alternative rather than the accepted one, plus it has better scoping rules, among other benefits:

            if pattern2.match(data) as match1:
                            result = match1.group(1)
            elif pattern2.match(data) as match2:
                            result = match2.group(2)
            else:
                            result = None

            vs

            if (match1 := pattern1.match(data)):
                            result = match1.group(1)
            elif (match2 := pattern.match(data)):
                            result = match2.group(2)
            else:
                            result = None

            • (Score: 0) by Anonymous Coward on Friday July 13 2018, @07:27PM

              by Anonymous Coward on Friday July 13 2018, @07:27PM (#706750)

              Oops, made some mispels in the last two examples on variable names, but the syntax is correct and my point still stands.