New assignmens ...

Chris Angelico rosuav at gmail.com
Sat Oct 23 17:05:21 EDT 2021


On Sun, Oct 24, 2021 at 7:48 AM Jon Ribbens via Python-list
<python-list at python.org> wrote:
>
> On 2021-10-23, Chris Angelico <rosuav at gmail.com> wrote:
> > On Sun, Oct 24, 2021 at 4:39 AM Jon Ribbens via Python-list
> ><python-list at python.org> wrote:
> >> On 2021-10-23, Chris Angelico <rosuav at gmail.com> wrote:
> >> > In what situations do you need to mutate an attribute and also test
> >> > it, and how much hassle is it to simply break it out into two lines?
> >>
> >> It's not hard to imagine something like:
> >>
> >>     def get_expensive(self):
> >>         return self.expensive or self.expensive := self.calculate_expensive()
> >
> > I usually write this sort of thing the other way:
> >
> > def get_expensive(self, key):
> >     if key not in self.cache:
> >         self.cache[key] = ...
> >     return self.cache[key]
> >
> > and then if you don't like the duplication, the cleanest way is to put
> > the expensive calculation into the __missing__ method of a dict
> > subclass.
>
> Sure, but if "there's already another way of doing it" was a winning
> argument then assignment expressions wouldn't have been accepted into
> the language at all.

There is always another way of doing it. The question is not so much
"is this something that's currently absolutely impossible?" but more
"how ugly is the current way of doing things?". Ugly is, of course,
somewhat subjective, but if the current way of doing things involves a
lot of extra hassle, or is error-prone, etc, etc, then there's room to
show improvement.

The original PEP showed this improvement in ways that involved simple
names. Expanding on this is a separate proposal.


> > Read over that document for an excellent example of how to take a
> > tight proposal and recommend that it be made more flexible. Assignment
> > expressions are currently in the restricted form, allowing only simple
> > names, and it's up to you to propose and demonstrate the value of the
> > increased flexibility.
>
> I think we're allowed to discuss things in this group without them
> having to turn into formal proposals. Personally I've never written
> a Python assignment expression, and I think it'll be a few years
> before Python 3.8 is old enough for them to be conveniently usable.

Well, if you don't use them, then you don't really have a horse in
this race, so it doesn't matter. Someone who *does* want to make use
of them can read over that document etc etc, and demonstrate the value
of the proposal.

BTW, it doesn't have to be a "formal proposal" in any sense; it just
needs to be a logical and reasonable argument showing the value of the
improvement (or the problems with the status quo).

ChrisA


More information about the Python-list mailing list