[Python-Dev] PEP 572: Assignment Expressions

Paul Moore p.f.moore at gmail.com
Fri Apr 20 08:51:37 EDT 2018


On 20 April 2018 at 12:25, Christoph Groth <christoph at grothesque.org> wrote:
>> Maybe not.  While it would be nice to solve the loop-and-a-half
>> "problem" and the loop variable initialization "problem" (not everyone
>> agrees these are even problems, especially now that we have
>> comprehensions and generator expressions), as a matter of taste I like
>> the fact that this particular class of side effects is given weighty
>> statement syntax rather than more lightweight expression syntax.
>
> I think that this is the crucial point.  If it is indeed a design
> principle of Python that expressions should not have the side-effect of
> assigning names, than the whole discussion of PEP 572 could have been
> stopped early on.  I didn't have this impression since core devs
> participated constructively in the discussion.

I don't think it's a "design principle" as such, but it *is* true that
until this point, functions with side effects excluded, Python's
expression syntax has not included any means of assigning names, and
that's expected behaviour (in the sense that when looking for where a
name could have been bound, Python programmers do not look closely at
the detail of expressions, because they can't be the source of an
assignment). This PEP explicitly changes that, and that's a fairly
radical change from current expectations.

As to why core devs participated in the discussion, I can't speak for
anyone else but for me:

1. PEPs deserve to be taken seriously - Chris put a lot of work into
this PEP and simply dismissing it isn't giving it a fair hearing. The
PEP didn't come out of nowhere, there had been previous discussions
that established it was worth writing a PEP.
2. I hadn't really thought of the PEP in those terms. Now that you've
mentioned it, "Python has never before had syntax that assigns names
from within an expression" is quite a significant change, and one the
PEP needs to examine the implications of. It's mostly been covered in
the discussions by now, of course.
3. It was of interest to me. Just because I'm interested in a proposal
doesn't necessarily mean it's a good idea.
4. I didn't like the idea much, and I wanted to raise my objections.
Maybe they could be addressed, maybe not, but participation doesn't
imply endorsement.

Paul


More information about the Python-Dev mailing list