Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.

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

    --
    "Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
    Starting Score:    1  point
    Moderation   +2  
       Interesting=1, Informative=1, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   4  

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

      --
      "Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin

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