[issue36761] Extended slice assignment + iterable unpacking

[wim glenn]

Change by wim glenn :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36761] Extended slice assignment + iterable unpacking

[wim glenn]

wim glenn  added the comment:

Serhiy,

`a, *L[::2] = "abc"` as an alternative is interesting, thanks.  The other 
example `L[:], *rest = 'abcdef'` is less interesting because L[:] can be 
arbitrary size.

When noticing this, I had tried to consume a generator into every other 
position in a list by using:

L[::2], *extra = g

Though there are obvious workarounds (e.g. using `itertools.islice`), it 
surprised me that CPython did not "do what I mean" out of the box. 

However, since creating the issue, it was brought to my attention that trying 
to handle this assignment may result in potential ambiguity, for example:

L = [0, 1, 2]
L[::2], *rest = "ab", "c", "d"

There is no obvious choice for result here. So, perhaps this issue should just 
be closed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36761] Extended slice assignment + iterable unpacking

[Windson Yang]

Windson Yang  added the comment:

In your first case, *any positive index except 2 will work*, For example:

L = [0, 1, 2]
L[::1], *rest = "abcdef" # L became ['a']
or 
L[::3], *rest = "abcdef" # L became ['a', 1, 2]

I found iff when you change the length of L to 1(L[::3]) or didn't change L at 
all (L[::1], L[::]), this expression will work. But I'm not sure that is what 
you expected.

--
nosy: +Windson Yang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36761] Extended slice assignment + iterable unpacking

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

For the second case, you can use

a, *L[::2] = "abc"

For the first case this does not work, because an assignment can have only one 
starred expression.

Making the first case to work as you expected is breaking change. Currently

L[:], *rest = 'abcdef'

sets L to ['a'] and rest to ['b', 'c', 'd', 'e', 'f']. Consistent implementing 
of your idea would set L to ['a', 'b', 'c'] and rest to ['d', 'e', 'f'] 
(because len(L[:]) == 3 before assignment).

What is your use case? Why do you need such syntax?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36761] Extended slice assignment + iterable unpacking

[SilentGhost]

Change by SilentGhost :


--
nosy: +georg.brandl, gvanrossum
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36761] Extended slice assignment + iterable unpacking

[wim glenn]

New submission from wim glenn :

Could cases like these be made to work? *Should* cases like these be made to 
work?

L = [0, 1, 2]
L[::2], *rest = "abcdef"
# ValueError: attempt to assign sequence of size 1 to extended slice of size 2

a, L[::2] = "abc"
# ValueError: too many values to unpack (expected 2)

The list slice knows exactly how many slots need to be filled, so I can't 
immediately think of any obvious ambiguity. Maybe there are some implementation 
complications with supporting e.g. generators on the RHS (because RHS must be 
evaluated before LHS - 
https://docs.python.org/3/reference/expressions.html#evaluation-order).

--
components: Interpreter Core
messages: 341160
nosy: wim.glenn
priority: normal
severity: normal
status: open
title: Extended slice assignment + iterable unpacking
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com