Congrats to Chris for breaking his PEP curse

Ian Kelly ian.g.kelly at gmail.com
Wed Jul 4 01:05:01 EDT 2018


Now that I've actually read the PEP (sorry, I just assumed it would
never fly), I have a couple of (tongue-in-cheek) observations about
it:

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

The only problem with this example of doing more work to save a line
of code is that presumably the same programmer would now instead
write:

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

This abomination serves to convince me that the people who said the
conditional expression should list the condition first were right.

Secondly, I believe the order of evaluation means that, much as I
would like to, I can't now write all my statements as:

f(f := lambda f: do_something())

Because the outer f will be evaluated before the argument expression
assigns it. Well, that's no fun. Is it too late to fix this? I'm only
half-joking here; if it worked, this would be a much better way to
pass a lambda to itself for recursion than the existing idiom:

(lambda f: lambda *a: f(f, *a))(lambda s, x: 1 if x==0 else x * s(s, x-1))(10)

That's a factorial function, in case you couldn't tell.

Oh well, at least now I'll be able to write exec(x := 'del x').
On Tue, Jul 3, 2018 at 8:04 PM Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
>
> Congratulations to Chris Angelico for breaking the dreaded "any PEP
> written by Chris will be rejected" curse :-)
>
> Guido has announced his intention to accept PEP 572 (assignment
> expressions) once the PEP has been cleaned up a bit.
>
> https://www.python.org/dev/peps/pep-0572/
>
> (The current version of the PEP doesn't quite match the proposal as
> nutted out over about a bazillion emails on two mailing lists starting in
> FEBRUARY!!!)
>
>
> Summary:
>
> Python 3.8 will allow an assignment-as-expression operator. The most
> common uses are expected to be if and while statements:
>
>     condition = expression
>     while condition:
>         do_something()
>         condition = expression
>
> will become:
>
>     while condition := expression:
>         do_something()
>
>
> Cascades of if statements, such as:
>
>     # the dreaded arrowhead anti-pattern
>     mo = re.match(pattern, text)
>     if mo:
>         ...
>     else:
>         mo = re.match(another_pattern, text):
>         if mo:
>             ...
>         else:
>             mo = re.match(third_pattern, text):
>             if mo:
>                 ...
>
>
> will become flatter and easier to read:
>
>     if mo := re.match(pattern, text):
>         ...
>     elif mo := re.match(another_pattern, text):
>         ...
>     elif mo := re.match(third_pattern, text):
>         ...
>
>
> FAQs:
>
> Q. Why Pascal's assignment operator := instead of regular = assignment?
>
> A. To avoid the C bug magnet of mistakenly writing "if x = expr" when
>    you intended to write "if x == expr".
>
>
> Q. Why not use "as"?
>
> A. There is an ambiguity due to with and except statements:
>
>     with expr as name
>
>     except Exception as name
>
>    are already permitted and mean something different to ordinary
>    assignment expressions.
>
>
> Q. Oh no, Python is doomed! This is the end of the world!
>
> A. That's not actually a question, is it?
>
>
>
>
> --
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson
>
> --
> https://mail.python.org/mailman/listinfo/python-list


More information about the Python-list mailing list