Dom Grigonis writes:
> This nuance can also be encountered in “principal use-case”. E.g.:
> class A:
> def func(self):
> while (self.a := 1) < 5:
> self.a += 1
> return self.a
Not sure what you're getting at here, that's an infloop. Did you mean
something like this:
class A:
def func(self):
while (self.a := self.a += 1) < 5:
pass
return self.a
I'm pretty sure that exact idiom, modeled on the C "copy string" idiom
void strcpy(char *s, char *t) {
while (*t++ = *s++)
would generally be considered unpythonic, but I suppose some people
might like it if instead of pass you had a real suite there. I think
it's a real "meh" use case, since in most cases it can be rewritten
class A:
def func(self):
while self.a < (5 - 1): # expression to make the
# transformation clear
self.a += 1
return self.a
and you save a couple characters and at most one line (none in the
case you present).
> Same argument as for “walrus” operator itself - convenient
> feature. Or is there more to it?
There's more to it. The loop and a half construct, where you execute
the body of the loop once outside the loop for some reason is widely
considered a really big wart (DRY failure). The walrus allows us to
eliminate most of those.
On the other hand, an assignment and a return statement are two
different things; it's not a DRY viotion to have the same identifier
in both.
> I was actually surprised that this didn’t work - I thought that
> this operator is a literal composite of assignment and “retriever",
> rather than having it’s own restrictive logic.
This is a common practice in Python development. Try a little bit of
a new idea, avoid engineering, and expand later if that seems useful
too.
> If it doesn’t break anything, doesn’t have any undesirable side
> effects and community likes it, then could be a good addition.
"Community likes it" is a null predicate, very hard to verify in edge
cases. When the support in the community is strong enough that
"community likes it" is common knowledge, it's always the case that
there are objective reasons why it's a good thing.
All additions have a 0 * infinity cost: a negligible cost of learning
(for one user) times *all* the users.
Other projects feel differently about it, but Python tends to be quite
conservative about additions.
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IFTS6XVVNAYXBMUBUB2FF6QX7BMFKXVQ/
Code of Conduct: http://python.org/psf/codeofconduct/
