I don't have an opinion one way or the other, but there is a discussion
on Discourse about the walrus operator:
https://discuss.python.org/t/walrus-fails-with/15606/1
Just a quick straw poll, how would people feel about relaxing the
restriction on the walrus operator so that iterable unpacking
On Sun, 8 May 2022 at 20:52, Steven D'Aprano wrote:
> Just a quick straw poll, how would people feel about relaxing the
> restriction on the walrus operator so that iterable unpacking is
> allowed?
>
> # Currently a syntax error.
> results = (1, 2, (a, b) := (3, 4), 5)
>
> which would crea
A while ago there was a discussion about allowing "match" patterns for the
walrus operator. This would cover iterable unpacking as you suggested along
with all the patterns allowed in match statements.
if [x, y, z] := re.match(r"...").groups():
print(x, y, z)
The walrus expression w
On Sun, 8 May 2022 at 22:09, Valentin Berlier wrote:
>
> A while ago there was a discussion about allowing "match" patterns for the
> walrus operator. This would cover iterable unpacking as you suggested along
> with all the patterns allowed in match statements.
>
> if [x, y, z] := re.match(
> What if it does match, though?
The walrus operator returns the value on the right side so this wouldn't
change. In your example the original dict would get printed.
some_dict = {"x": 1, "y": 2}
print({"x": x} := some_dict) # {"x": 1, "y": 2}
The only pattern where it's not possible to know
On Mon, 9 May 2022 at 00:04, Valentin Berlier wrote:
>
> > What if it does match, though?
>
> The walrus operator returns the value on the right side so this wouldn't
> change. In your example the original dict would get printed.
>
> some_dict = {"x": 1, "y": 2}
> print({"x": x} := some_dict) #
> Yes, but what if you're testing for something that could *potentially* match
> one of these empty objects?
The right side can absolutely be falsy but to be able to conflate the falsy
return value with the None emitted when the pattern doesn't match, the left
side has to be one of the dubious
On 2022-05-08 11:50, Steven D'Aprano wrote:
I don't have an opinion one way or the other, but there is a discussion
on Discourse about the walrus operator:
https://discuss.python.org/t/walrus-fails-with/15606/1
Just a quick straw poll, how would people feel about relaxing the
restriction on th
On 2022-05-08 13:44, Chris Angelico wrote:
On Sun, 8 May 2022 at 22:09, Valentin Berlier wrote:
A while ago there was a discussion about allowing "match" patterns for the
walrus operator. This would cover iterable unpacking as you suggested along with all the
patterns allowed in match statem
On Mon, 9 May 2022 at 00:58, Valentin Berlier wrote:
>
> In your example "if ([x] := foo()) is not None:" there is no possible value
> returned by foo() that could be both falsy and match the [x] pattern at the
> same time. All patterns besides the ones I listed can only be matched by
> truthy
On Mon, 9 May 2022 at 01:07, MRAB wrote:
>
> On 2022-05-08 13:44, Chris Angelico wrote:
> > On Sun, 8 May 2022 at 22:09, Valentin Berlier wrote:
> >>
> >> A while ago there was a discussion about allowing "match" patterns for the
> >> walrus operator. This would cover iterable unpacking as you s
Yeah you can technically craft such pathological edge cases but this is already
heavily discouraged. Libraries that change the usual semantics of python's
object model are rare.
The only exception I can think of would be numpy which disallows truthiness
checks because of the ambiguity of arrays
On Sun, May 08, 2022 at 03:59:07PM +0100, MRAB wrote:
> > # Currently a syntax error.
> > results = (1, 2, (a, b) := (3, 4), 5)
> >
> Doesn't ':=' have a lower precedence than ',', so you're effectively
> asking it to bind:
>
> (1, 2, (a, b))
>
> to:
>
> ((3, 4), 5)
Possibly.
On Sun, May 08, 2022 at 04:00:47PM +0100, Rob Cliffe wrote:
> Yes, I know unrestricted use of the walrus can lead to obfuscated code
> (and some of Steven's examples below might be cited as instances 😁).
They're intended as the simplest, least obfuscatory examples of using
the walrus operator
I have not personally ever used the walrus operator, and I don't think I've
even seen it used in the wild, either.
That's not a commentary on how useful it is, but that it takes time for
changes like this (that can't be back-ported) to get much real world use.
So no, I don't think it's time to re
On 5/8/22 05:08, Valentin Berlier wrote:
> This would make it really useful in if statements and list comprehensions.
Here are a couple motivating examples:
>
> # Buy every pizza on the menu
> cost_for_all_pizzas = sum(
> price for food in menu
> if ({"type": "piz
On Sun, 8 May 2022 at 19:38, Ethan Furman wrote:
>
> On 5/8/22 05:08, Valentin Berlier wrote:
>
>
> > This would make it really useful in if statements and list comprehensions.
> Here are a couple motivating examples:
> >
> > # Buy every pizza on the menu
> > cost_for_all_pizzas =
> Doesn't ':=' have a lower precedence than ','
No it doesn't. Its precedence is between ',' and a single non-name expression,
so you can effectively do this:
\>>> (1, 2, a := 3, 4)
(1, 2, 3, 4)
\>>> a
3
___
Python-ideas mailing list -- python-ideas@pyth
On Sun, 8 May 2022 at 20:52, Steven D'Aprano wrote:
> Just a quick straw poll, how would people feel about relaxing the
> restriction on the walrus operator so that iterable unpacking is
> allowed?
>
> # Currently a syntax error.
> results = (1, 2, (a, b) := (3, 4), 5)
>
> which would crea
On Mon, 9 May 2022 at 07:36, Jeremiah Vivian
wrote:
>
> On Sun, 8 May 2022 at 20:52, Steven D'Aprano wrote:
> > Just a quick straw poll, how would people feel about relaxing the
> > restriction on the walrus operator so that iterable unpacking is
> > allowed?
> >
> > # Currently a syntax erro
20 matches
Mail list logo
