[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 error. > > results = (1, 2, (a, b) := (3, 4), 5) > > > > which would create the following bindings: > > > > results = (1, 2, (3, 4), 5) > > a = 3 > > b = 4 > > I've always thought of relaxing the restrictions. It's actually easy to > implement (even including attribute assignment/subscript assignment) and I > had to modify only two files (plus regenerate the parser). > The restrictions were never technical. They were always social - too many people were scared that assignment expressions would lead to a plethora of problems. (Which is not unreasonable. Guido made assignment a statement very deliberately, back when Python was first created. Changing that decision, or even modifying it slightly, should indeed be thoroughly thought out.) Requiring that the target be a simple name only was one way to minimize the risk. ChrisA ___ 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/4QHZQTA73B66GGGNVWRXM73M5OEX3GOI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 create the following bindings: > > results = (1, 2, (3, 4), 5) > a = 3 > b = 4 I've always thought of relaxing the restrictions. It's actually easy to implement (even including attribute assignment/subscript assignment) and I had to modify only two files (plus regenerate the parser). ___ 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/7LVZLFS4PVJDJF43SVLGCXODDG6BEYLW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
> 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@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/I3Z2LHVYJUWQF5FD45OBU4GR537KVNM6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 = sum(
> > price for food in menu
> > if ({"type": "pizza", "price": price} := food)
> > )
>
> What exactly is that last line testing, and how does it differentiate between
> "pizza" and, say, "salad"?
And what is wrong with
cost_for_all_pizzas = 0
for food in menu:
match food:
case {"type": "pizza", "price": price}:
cost_for_all_pizzas += price
Seriously, people are just getting used to match statements (I had to
look the syntax up for the above) so IMO it's a bit early to be trying
to cram them into dubious one-liners.
Paul.
___
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/XRBWE4AMN754NNYZNTT3XEJUQ4N7P46D/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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": "pizza", "price": price} := food)
> )
What exactly is that last line testing, and how does it differentiate between "pizza"
and, say, "salad"?
--
~Ethan~
___
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/UUGWJOOOLKTMMG65QDTWYOPP5QF23MYI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on 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 relax the restrictions -- for the same reason the restrictions were there in the first place. - CHB On Sun, May 8, 2022 at 9:40 AM Steven D'Aprano wrote: > 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 that is not pointless. That is, an example of the > walrus as a sub-expression embedded inside another expression. > > If you think my examples are obfuscated, then that is an argument in > favour of keeping the status quo. > > I could have given an example like this: > > ((a, b) := [1, 2]) > > but there is no good reason to use the walrus operator there, it is not > a sub-expression, and it Just Works if you use the assignment statement > instead. > > -- > 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/S7MU7ONVRAVYPXYTYMRGW32NYU3L7RIE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/PXKS5WHB57KK5QM32IWHVOYOAZRUMX5W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 that is not pointless. That is, an example of the walrus as a sub-expression embedded inside another expression. If you think my examples are obfuscated, then that is an argument in favour of keeping the status quo. I could have given an example like this: ((a, b) := [1, 2]) but there is no good reason to use the walrus operator there, it is not a sub-expression, and it Just Works if you use the assignment statement instead. -- 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/S7MU7ONVRAVYPXYTYMRGW32NYU3L7RIE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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. Insert additional parentheses as needed to make it work :-) results = (1, 2, ((a, b) := (3, 4)), 5) -- 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/SLMS6N7Y6GGS7ACNWOD77QA5D5WMJZCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 being both scalars and containers. However, this means that the "if x := get_some_array():" construct is already ill-formed so nothing would change by generalizing the left side to arbitrary patterns. And since numpy arrays aren't proper Sequence types you can't use them with the current implementation of pattern matching anyway. So besides carefully crafted pathological edge-cases the "if (...) is not None" construct would be completely redundant. ___ 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/332DUWASBGXRPUHQN2AVEKTV2ASILKLB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 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 would evaluate to None if the pattern on the left
> >> can't be matched.
> >>
> >
> > What if it does match, though? That's a little less clear. I like the
> > idea, but I'm not entirely sure what this should do, for instance:
> >
> > print( {"x": x} := some_dict )
> >
> > Clearly it should assign x to some_dict["x"] if possible, but then
> > what should get printed out? A small dict with one key/value pair? The
> > original dict? There would need to be a guarantee that the return
> > value is truthy, otherwise it'll create bizarre situations where you
> > try to match and it looks as if the match failed.
> >
> Perhaps the solution would be to add another operator, "?=", that would
> return True if the binding succeeded and False if it failed.
>
It doesn't actually even need to be a different operator. There is
currently no semantic meaning for "pattern := expr" save in the strict
case where the pattern is a simple name, so semantics can be granted
according to what's most useful.
ChrisA
___
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/QXZD3OMGQ6EJTJCE5SBSRGXWAMPI2IBL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 values so the work-around would only be needed for those dubious
> patterns.
>
Do you count pathological examples?
class FakeEmpty(list):
def __bool__(self): return False
borked = FakeEmpty(("zero",))
match borked:
case [x]:
if borked: print("It's iterable.", x)
else: print("Wut")
case _: print("It's not [x].")
"No possible value" ought to exclude anything that can be created with
a couple of lines of Python like this. I could accept "no
non-pathological values" for the [x] case, but are there any match
types that could unexpectedly match a falsy value in normal
circumstances?
I'm *really* not a fan of having to put "if () is not None" just
to work around a rare possibility, but I'm even less a fan of lurking
bugs waiting to strike (think about how datetime.time() used to be
false for midnight). Boilerplate to dodge bugs is C's job, not
Python's.
ChrisA
___
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/YH74BMWMNS34ABEKUTFUVL3AJACJSFH7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 statements.
if [x, y, z] := re.match(r"...").groups():
print(x, y, z)
The walrus expression would evaluate to None if the pattern on the left can't
be matched.
What if it does match, though? That's a little less clear. I like the
idea, but I'm not entirely sure what this should do, for instance:
print( {"x": x} := some_dict )
Clearly it should assign x to some_dict["x"] if possible, but then
what should get printed out? A small dict with one key/value pair? The
original dict? There would need to be a guarantee that the return
value is truthy, otherwise it'll create bizarre situations where you
try to match and it looks as if the match failed.
Perhaps the solution would be to add another operator, "?=", that would
return True if the binding succeeded and False if it failed.
By the way: With any proposal to further generalize assignment
expressions, it'd be good to keep in mind the "implicit nonlocal"
effect that they currently have with comprehensions:
def f():
... x, y = "old x", "old y"
... print([(x := "new x") for y in ["new y"]])
... return x, y
...
f()
['new x']
('new x', 'old y')
My best guess is that this effect should be extended to any simple
names that could _potentially_ be assigned to, even if (as in the case
of some match expressions) they might not all actually be assigned to.
___
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/424EUXP35RIXQTJRCOZQCZPRHY7HT5F5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 the walrus operator so that iterable unpacking is
allowed?
# 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)
?
which would create the following bindings:
results = (1, 2, (3, 4), 5)
a = 3
b = 4
A more complex example:
expression = "uvwxyz"
results = (1, 2, ([a, *b, c] := expression), 5)
giving:
results = (1, 2, "uvwxyz", 5)
a = "u"
b = ("v", "w", "x", "y")
c = "z"
Thoughts?
___
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/7IYW3X6RPEMWCTFR42Q4U7FTV3MXL6GX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
> 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 patterns I listed. > I'm worried that this will end up being a bug magnet, or conversely, that > people will have to work around it with "if ([x] := foo()) is not None:", > which is way too clunky. 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 values so the work-around would only be needed for those dubious patterns. I think I'll experiment with a prototype when I have more time. ___ 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/VFRVYISEETRVZE6ODA72L7I3V63M6KY7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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) # {"x": 1, "y": 2}
>
> The only pattern where it's not possible to know if the pattern was matched
> by looking at the return value is the None pattern:
>
> print(None := x)
>
> If the pattern matches this will print the value of x, None, and if the
> pattern doesn't match this will also print None because the walrus operator
> evaluates to None instead of the value on the right side when the pattern
> doesn't match. This is not a problem since testing for None is normally done
> with the is operator: x is None
>
>
> The only patterns where it's not possible to know if the pattern was matched
> by looking at the truthiness of the return values are the following:
>
> print(None := x)
> print(False := x)
> print(0 := x)
> print(0.0 := x)
> print("" := x)
> print([] := x)
> print({} := x)
>
> This is not a problem since in all of these cases testing for truthiness is
> normally done with bool() or by testing the value directly in an if statement.
Yes, but what if you're testing for something that could *potentially*
match one of these empty objects? There's a reason that re.match
always returns a match object, NOT the matched string, because if a
regex matches an empty string, "if re.match(...)" should still count
it as true.
> In my opinion the behavior is fairly unsurprising: return the right side if
> the pattern matches or None otherwise. We can even explain the current
> restricted behavior in terms of pattern matching: the name on the left side
> is an "irrefutable" pattern which will always match and therefore always
> return the right side of the expression.
>
There will always be edge cases, though. Maybe pathological ones, but
edge cases nonetheless. I'm worried that this will end up being a bug
magnet, or conversely, that people will have to work around it with
"if ([x] := foo()) is not None:", which is way too clunky.
But I would like to see something like this happen. A match expression
is also something people have wanted from time to time.
ChrisA
___
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/LHY4XODZNZOGMJXVRCDTGIT765BRMJL5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
> 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 if the pattern was matched by
looking at the return value is the None pattern:
print(None := x)
If the pattern matches this will print the value of x, None, and if the pattern
doesn't match this will also print None because the walrus operator evaluates
to None instead of the value on the right side when the pattern doesn't match.
This is not a problem since testing for None is normally done with the is
operator: x is None
The only patterns where it's not possible to know if the pattern was matched by
looking at the truthiness of the return values are the following:
print(None := x)
print(False := x)
print(0 := x)
print(0.0 := x)
print("" := x)
print([] := x)
print({} := x)
This is not a problem since in all of these cases testing for truthiness is
normally done with bool() or by testing the value directly in an if statement.
In my opinion the behavior is fairly unsurprising: return the right side if the
pattern matches or None otherwise. We can even explain the current restricted
behavior in terms of pattern matching: the name on the left side is an
"irrefutable" pattern which will always match and therefore always return the
right side of the expression.
___
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/YQRKWVCEAQ7D67ODF74IVBDLVXAQGQOL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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(r"...").groups():
> print(x, y, z)
>
> The walrus expression would evaluate to None if the pattern on the left can't
> be matched.
>
What if it does match, though? That's a little less clear. I like the
idea, but I'm not entirely sure what this should do, for instance:
print( {"x": x} := some_dict )
Clearly it should assign x to some_dict["x"] if possible, but then
what should get printed out? A small dict with one key/value pair? The
original dict? There would need to be a guarantee that the return
value is truthy, otherwise it'll create bizarre situations where you
try to match and it looks as if the match failed.
By the way: With any proposal to further generalize assignment
expressions, it'd be good to keep in mind the "implicit nonlocal"
effect that they currently have with comprehensions:
>>> def f():
... x, y = "old x", "old y"
... print([(x := "new x") for y in ["new y"]])
... return x, y
...
>>> f()
['new x']
('new x', 'old y')
>>>
My best guess is that this effect should be extended to any simple
names that could _potentially_ be assigned to, even if (as in the case
of some match expressions) they might not all actually be assigned to.
ChrisA
___
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/UCGT2ZSA6Y5DOMMRJE7LVJGZXRRDAU45/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 would evaluate to None if the pattern on the left can't
be matched.
print(x := 42) # 42
print(1 := 42) # None
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": "pizza", "price": price} := food)
)
# Monitor service health
while Response(status=200, json={"stats": stats}) := health_check():
print(stats)
time.sleep(5)
___
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/HC7TAUYFTDMP52KAGDJFIB27KFSSI6C3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
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 create the following bindings: > > results = (1, 2, (3, 4), 5) > a = 3 > b = 4 I'd be in favour. But then, I was always in favour of it being more general, so that's not much of a data point :) ChrisA ___ 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/OCGHWF33NM62GSNB5QUBNGIKP7THRYVG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Time to relax some restrictions on the walrus operator?
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 is
allowed?
# Currently a syntax error.
results = (1, 2, (a, b) := (3, 4), 5)
which would create the following bindings:
results = (1, 2, (3, 4), 5)
a = 3
b = 4
A more complex example:
expression = "uvwxyz"
results = (1, 2, ([a, *b, c] := expression), 5)
giving:
results = (1, 2, "uvwxyz", 5)
a = "u"
b = ("v", "w", "x", "y")
c = "z"
Thoughts?
--
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/5CWWY4EZKXLJZD47NSQA6TRD5SWMFGOJ/
Code of Conduct: http://python.org/psf/codeofconduct/
