Re: 2 Bugs: in Python 3 tutorial, and in bugs.python.org tracker registration system

[Peter Otten]

Francis Esmonde-White wrote:

> Hello,
> 
> I came to report one bug (in the Python 3 tutorial documentation), and ran
> into another (functional in bugs.python.org bug tracker registration
> system). I have included details for both bugs below.
> 
> Thanks in advance for your assistance, I am loving Python and the
> documentation!
> 
> Warm regards,
> Francis Esmonde-White
> 
> ###
> 
> *Bug 1:*
> In the Python 3 tutorial section 9.8 for iterators
> , the example
> code for the iterator class Reverse has the iterator self.index defined
> only in the __init__. This approach will only allow the iterator to run
> once. Would it be better to show an example with the index defined as both
> a private field (self._index) and with the index value being populated in
> the __index__() function so that the method can be run more than once?
> 
> I think that the code example should look like the following:
> 
> class Reverse:
> """Iterator for looping over a sequence backwards."""
> def __init__(self, data):
> self.data = data
> 
> def __iter__(self):
> # Define the setup for the iteration here,
> # so that the index is always right when the iteration starts.
> self._index = len(self.data)
> return self
> 
> def __next__(self):
> if self._index == 0:
> raise StopIteration
> self._index = self._index - 1
> return self.data[self._index]

No, "iterators" are meant to be one-off, and their __iter__ method should 
just return self, while "iterables" give you a new iterater on each 
invocation of __iter__.

You can easily build an iterable on top of the Reverse class in the tutorial 
(see ReverseIterable below). You could also turn Reverse into an iterable, 
but your implementation is something in between with confusing behaviour. 
Compare:

class Reverse:
"""Iterator for looping over a sequence backwards."""
def __init__(self, data):
self.data = data
self.index = len(data)

def __iter__(self):
return self

def __next__(self):
if self.index == 0:
raise StopIteration
self.index = self.index - 1
return self.data[self.index]

class ReverseFrancis:
"""Iterator for looping over a sequence backwards."""
def __init__(self, data):
self.data = data

def __iter__(self):
# Define the setup for the iteration here,
# so that the index is always right when the iteration starts.
self._index = len(self.data)
return self

def __next__(self):
if self._index == 0:
raise StopIteration
self._index = self._index - 1
return self.data[self._index]

class ReverseIterable:
def __init__(self, data):
self.data = data
def __iter__(self):
return Reverse(self.data)

data = range(5)
for class_ in Reverse, ReverseIterable, ReverseFrancis:
print(class_.__name__)
it = class_(data)
for pair in zip(it, it):
iter(it)
print(*pair)

$ python3 tmp.py | head
Reverse
4 3
2 1
ReverseIterable
4 4
3 3
2 2
1 1
0 0
ReverseFrancis
4 3
4 3
4 3
4 3
4 3
4 3
4 3
4 3
4 3
4 3
Traceback (most recent call last):
  File "tmp.py", line 45, in 
print(*pair)
BrokenPipeError: [Errno 32] Broken pipe
$

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 2 Bugs: in Python 3 tutorial, and in bugs.python.org tracker registration system

[Brian Oney via Python-list]

That's one thing that confused me. Generators are supposed to be one-off 
iterators. Iterators, *I understood* as reusable iterables.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 2 Bugs: in Python 3 tutorial, and in bugs.python.org tracker registration system

[Cameron Simpson]

On 22Sep2018 12:08, Brian Oney  wrote:

That's one thing that confused me. Generators are supposed to be one-off 
iterators. Iterators, *I understood* as reusable iterables.


You've misread the grammar (the semantics). Iterators are one off - they're 
something that counts (for want of a better word which isn't "iterates") though 
something.


An _iterable_ is something which can be iterated over, and therefore is 
something from which an iterator can be made to do that.


So an iterator is what does the iterating, a single pass over whatever it is.

An iterable is something you can iterate over, using an iterator.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[Victor via Python-list]

Let me use a different input args and display them below.  Basically, I am 
hoping to add up all elements of each nested list.  So at first it should start 
with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take the 1st 
element from each nested list to add up [1,2,3] = 6.   How should it be 
corrected?  Thx.


>>> alist = [[1,11,111], [2,22,222], [3,33,333]]

>>> list(map(add_all_elements,*alist))
My args =  (1, 2, 3)

i = 1
BEFORE total = 0
AFTER total = 1


i = 2
BEFORE total = 1
AFTER total = 3


i = 3
BEFORE total = 3
AFTER total = 6

FINAL total = 6

My args =  (11, 22, 33)

i = 11
BEFORE total = 0
AFTER total = 11


i = 22
BEFORE total = 11
AFTER total = 33


i = 33
BEFORE total = 33
AFTER total = 66

FINAL total = 66

My args =  (111, 222, 333)

i = 111
BEFORE total = 0
AFTER total = 111


i = 222
BEFORE total = 111
AFTER total = 333


i = 333
BEFORE total = 333
AFTER total = 666

FINAL total = 666

[6, 66, 666]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[Peter Otten]

Victor via Python-list wrote:

> Let me use a different input args and display them below.  Basically, I am
> hoping to add up all elements of each nested list.  So at first it should
> start with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take
> the 1st element from each nested list to add up [1,2,3] = 6.   How should
> it be corrected?  Thx.

I see three options. You can

(1) use a list comprehension

[add_all_elements(*sub) for sub in alist]

(2) replace map() with itertools.starmap()

list(itertools.starmap(add_all_elements, alist))

(3) change your function's signature from add_all_elements(*args) to 
add_all_elements(args), either by modifying it directly or by wrapping it 
into another function

list(map(lambda args: add_all_elements(*args), alist))

(3a) My personal preference would be to change the signature and then use 
the list comprehension

def add_all_elements(args): ...
[add_all_elements(sub) for sub in alist]

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 2 Bugs: in Python 3 tutorial, and in bugs.python.org tracker registration system

[Peter Otten]

Brian Oney via Python-list wrote:

> That's one thing that confused me. Generators are supposed to be one-off
> iterators. Iterators, *I understood* as reusable iterables.

The way I think about it, informally: iterables need and __iter__ method, 
iterators need a __next__ method.

In practice all iterators are also iterables, and the convention is to have 
__iter__ return self, which makes them one-off. 

Generators are just iterators created in an elegant way, by a function 
containing yield-s.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explicit vararg values

[Buck Evan]

Received?

On Sun, Sep 16, 2018 at 3:39 PM Buck Evan  wrote:

> I started to send this to python-ideas, but I'm having second thoughts.
> Does tihs have merit?
>
> ---
> I stumble on this a lot, and I see it in many python libraries:
>
> def f(*args, **kwargs):
> ...
>
> f(*[list comprehension])
> f(**mydict)
>
> It always seems a shame to carefully build up an object in order to
> explode it, just to pack it into a near-identical object.
>
> Today I was fiddling with the new python3.7 inspect.signature
> functionality when I ran into this case:
>
> def f(**kwargs): pass
> sig = inspect.signature(f)
> print(sig.bind(a=1, b=2))
>
> The output is "". I found this a
> bit humorous since anyone attempting to bind values in this way, using
> f(kwargs={'a': 1, 'b': 2}) will be sorely dissappointed. I also wondered
> why BoundArguments didn't print '**kwargs' since that's the __str__ of that
> parameter object.
>
> The syntax I'm proposing is:
>f(**kwargs={'a': 1, 'b': 2})
>
> as a synonym of f(a=1, b=2) when an appropriate dictionary is already on
> hand.
>
> ---
> I can argue for this another way as well.
>
> 1)
> When both caller and callee have a known number of values to pass/receive,
> that's the usual syntax:
> def f(x) and f(1)
>
> 2)
> When the caller has a fixed set of values, but the callee wants to handle
> a variable number:   def f(*args) and f(1)
>
> 3)
> Caller has a variable number of arguments (varargs) but the call-ee is
> fixed, that's the splat operator: def f(x) and f(*args)
>
> 4)
> When case 1 and 3 cross paths, and we have a vararg in both the caller and
> callee, right now we're forced to splat both sides: def f(*args) and
> f(*args), but I'd like the option of opting-in to passing along my list
> as-is with no splat or collection operations involved: def f(*args) and
> f(*args=args)
>
> Currently the pattern to handle case 4 neatly is to define two versions of
> a vararg function:
>
> def f(*arg, **kwargs):
> return _f(args, kwargs)
>
> return _f(args, kwargs):
> ...
>
> Such that when internal calllers hit case 4, there's a simple and
> efficient way forward -- use the internal de-vararg'd  definition of f.
> External callers have no such option though, without breaking protected api
> convention.
>
> My proposal would simplify this implementation as well as allowing users
> to make use of a similar calling convention that was only provided
> privately before.
>
> Examples:
>
> log(*args) and _log(args) in logging.Logger
> format and vformat of strings.Formatter
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[Victor via Python-list]

On Saturday, September 22, 2018 at 6:22:32 AM UTC-7, Peter Otten wrote:
> Victor via Python-list wrote:
> 
> > Let me use a different input args and display them below.  Basically, I am
> > hoping to add up all elements of each nested list.  So at first it should
> > start with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take
> > the 1st element from each nested list to add up [1,2,3] = 6.   How should
> > it be corrected?  Thx.
> 
> I see three options. You can
> 
> (1) use a list comprehension
> 
> [add_all_elements(*sub) for sub in alist]
> 
> (2) replace map() with itertools.starmap()
> 
> list(itertools.starmap(add_all_elements, alist))
> 
> (3) change your function's signature from add_all_elements(*args) to 
> add_all_elements(args), either by modifying it directly or by wrapping it 
> into another function
> 
> list(map(lambda args: add_all_elements(*args), alist))
> 
> (3a) My personal preference would be to change the signature and then use 
> the list comprehension
> 
> def add_all_elements(args): ...
> [add_all_elements(sub) for sub in alist]

Hi Peter,
Thank you for your suggested solutions.  They all work.  But I just want to 
know what is wrong with my doing:

list(map(add_all_elements,*alist))

Theoretically, each list element is passed to add_all_elements.  And if my 
alist is [[1, 11, 111], [2, 22, 222], [3, 33, 333]], then the 1st list element  
must be this [1,11,111] passed as args into add_all_elements.  

In other words, the following should have happened:  

>>> add_all_elements (*[1,11,111])
My args =  (1, 11, 111)

i = 1
BEFORE total = 0
AFTER total = 1

i = 11
BEFORE total = 1
AFTER total = 12

i = 111
BEFORE total = 12
AFTER total = 123

FINAL total = 123

123

Again, thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Problema na DLL

[Allan Sobrero]

Olá, estou tendo problemas para executar o Python, baixei a versão 64 bit
pois nas configurações de meu computador mostra 64x, porém na hora de
executar diz que não tenho o api-ms-win-crt-runtime-l1-1-0.dll
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[Peter Otten]

Victor via Python-list wrote:

> On Saturday, September 22, 2018 at 6:22:32 AM UTC-7, Peter Otten wrote:
>> Victor via Python-list wrote:
>> 
>> > Let me use a different input args and display them below.  Basically, I
>> > am
>> > hoping to add up all elements of each nested list.  So at first it
>> > should
>> > start with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to
>> > take
>> > the 1st element from each nested list to add up [1,2,3] = 6.   How
>> > should
>> > it be corrected?  Thx.
>> 
>> I see three options. You can
>> 
>> (1) use a list comprehension
>> 
>> [add_all_elements(*sub) for sub in alist]
>> 
>> (2) replace map() with itertools.starmap()
>> 
>> list(itertools.starmap(add_all_elements, alist))
>> 
>> (3) change your function's signature from add_all_elements(*args) to
>> add_all_elements(args), either by modifying it directly or by wrapping it
>> into another function
>> 
>> list(map(lambda args: add_all_elements(*args), alist))
>> 
>> (3a) My personal preference would be to change the signature and then use
>> the list comprehension
>> 
>> def add_all_elements(args): ...
>> [add_all_elements(sub) for sub in alist]
> 
> Hi Peter,
> Thank you for your suggested solutions.  They all work.  But I just want
> to know what is wrong with my doing:
> 
> list(map(add_all_elements,*alist))
> 
> Theoretically, each list element is passed to add_all_elements.  And if my
> alist is [[1, 11, 111], [2, 22, 222], [3, 33, 333]], then the 1st list
> element  must be this [1,11,111] passed as args into add_all_elements.
> 
> In other words, the following should have happened:
> 
 add_all_elements (*[1,11,111])

That's not what happens. Try it with a function that passes through its 
arguments unchanged:

>>> items = [[1, 11, 111], [2, 22, 222], [3, 33, 333]]
>>> list(map(lambda *args: args, *items))
[(1, 2, 3), (11, 22, 33), (111, 222, 333)]

The star before items is evaluated directly rather than magically passed on 
to the call of add_all_elements.

map(f, *items)

is equivalent to

map(f, items[0], items[1], items[2])

which calls f with

f(items[0][0], items[1][0], items[2][0])
f(items[0][1], items[1][1], items[2][1])
f(items[0][2], items[1][2], items[2][2])

If you think of your list of lists as a matrix that matrix is effectively 
transposed (x and y axis are swapped).

>>> list(map(lambda *args: sum(args), *items))
[6, 66, 666]

In principle you could transpose the matrix twice

>>> list(map(lambda *args: sum(args), *zip(*items)))
[123, 246, 369]

but that's not a very efficient approach.

Another gotcha to be aware of is that map() (and zip()) stop when the 
shortest argument ends:

>>> list(map(lambda *args: sum(args), [], *items))
[]
>>> list(map(lambda *args: sum(args), [42], *items))
[48]
>>> list(map(lambda *args: sum(args), [42, 42], *items))
[48, 108]
>>> list(map(lambda *args: sum(args), [42, 42, 42, 42, 42], *items))
[48, 108, 708]


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[Thomas Jollans]

On 22/09/2018 20:18, Victor via Python-list wrote:

On Saturday, September 22, 2018 at 6:22:32 AM UTC-7, Peter Otten wrote:

Victor via Python-list wrote:


Let me use a different input args and display them below.  Basically, I am
hoping to add up all elements of each nested list.  So at first it should
start with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take
the 1st element from each nested list to add up [1,2,3] = 6.   How should
it be corrected?  Thx.


I see three options. You can

(1) use a list comprehension

[add_all_elements(*sub) for sub in alist]

(2) replace map() with itertools.starmap()

list(itertools.starmap(add_all_elements, alist))

(3) change your function's signature from add_all_elements(*args) to
add_all_elements(args), either by modifying it directly or by wrapping it
into another function

list(map(lambda args: add_all_elements(*args), alist))

(3a) My personal preference would be to change the signature and then use
the list comprehension

def add_all_elements(args): ...
[add_all_elements(sub) for sub in alist]


Hi Peter,
Thank you for your suggested solutions.  They all work.  But I just want to 
know what is wrong with my doing:

list(map(add_all_elements,*alist))

Theoretically, each list element is passed to add_all_elements.  And if my 
alist is [[1, 11, 111], [2, 22, 222], [3, 33, 333]], then the 1st list element  
must be this [1,11,111] passed as args into add_all_elements.


Now,

  alist = [[1,11,111], [2,22,222], [3,33,333]]

so `map(add_all_alements, *alist)` is equivalent to

  map(add_all_elements,
  [1,11,111],
  [2,22,222],
  [3,33,333])

According to the docs [1], map(function, iterable, ...)

"applies function to every item of iterable, yielding the results. If 
additional iterable arguments are passed, function must take that many 
arguments and is applied to the items from all iterables in parallel."


So map takes the first item(s) of the argument(s), and applies the 
function to them, followed by the second item(s), and so on.


In other words:

def map(function, *iterables):
for args in zip(iterables):
yield function(*args)


[1] https://docs.python.org/3/library/functions.html#map

Come to think of it, this suggests a rather silly alternative "solution":

map(add_all_elements, *zip(*alist))



In other words, the following should have happened:


add_all_elements (*[1,11,111])

My args =  (1, 11, 111)

i = 1
BEFORE total = 0
AFTER total = 1

i = 11
BEFORE total = 1
AFTER total = 12

i = 111
BEFORE total = 12
AFTER total = 123

FINAL total = 123

123

Again, thanks!



--
https://mail.python.org/mailman/listinfo/python-list

Re: Problema na DLL

[Thomas Jollans]

On 22/09/2018 19:28, Allan Sobrero wrote:

Olá, estou tendo problemas para executar o Python, baixei a versão 64 bit
pois nas configurações de meu computador mostra 64x, porém na hora de
executar diz que não tenho o api-ms-win-crt-runtime-l1-1-0.dll



https://support.microsoft.com/pt-pt/help/2999226/update-for-universal-c-runtime-in-windows

The link above should solve your immediate problem.

This is an English-language list. Resources and community mailing 
lists/forums in other languages can be found elsewhere. You may be 
interested in:


https://python.org.br
https://wiki.python.org/moin/PortugueseLanguage
--
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[Victor via Python-list]

On Saturday, September 22, 2018 at 12:20:08 PM UTC-7, Thomas Jollans wrote:
> On 22/09/2018 20:18, Victor via Python-list wrote:
> > On Saturday, September 22, 2018 at 6:22:32 AM UTC-7, Peter Otten wrote:
> >> Victor via Python-list wrote:
> >>
> >>> Let me use a different input args and display them below.  Basically, I am
> >>> hoping to add up all elements of each nested list.  So at first it should
> >>> start with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take
> >>> the 1st element from each nested list to add up [1,2,3] = 6.   How should
> >>> it be corrected?  Thx.
> >>
> >> I see three options. You can
> >>
> >> (1) use a list comprehension
> >>
> >> [add_all_elements(*sub) for sub in alist]
> >>
> >> (2) replace map() with itertools.starmap()
> >>
> >> list(itertools.starmap(add_all_elements, alist))
> >>
> >> (3) change your function's signature from add_all_elements(*args) to
> >> add_all_elements(args), either by modifying it directly or by wrapping it
> >> into another function
> >>
> >> list(map(lambda args: add_all_elements(*args), alist))
> >>
> >> (3a) My personal preference would be to change the signature and then use
> >> the list comprehension
> >>
> >> def add_all_elements(args): ...
> >> [add_all_elements(sub) for sub in alist]
> > 
> > Hi Peter,
> > Thank you for your suggested solutions.  They all work.  But I just want to 
> > know what is wrong with my doing:
> > 
> > list(map(add_all_elements,*alist))
> > 
> > Theoretically, each list element is passed to add_all_elements.  And if my 
> > alist is [[1, 11, 111], [2, 22, 222], [3, 33, 333]], then the 1st list 
> > element  must be this [1,11,111] passed as args into add_all_elements.
> 
> Now,
> 
>alist = [[1,11,111], [2,22,222], [3,33,333]]
> 
> so `map(add_all_alements, *alist)` is equivalent to
> 
>map(add_all_elements,
>[1,11,111],
>[2,22,222],
>[3,33,333])
> 
> According to the docs [1], map(function, iterable, ...)
> 
> "applies function to every item of iterable, yielding the results. If 
> additional iterable arguments are passed, function must take that many 
> arguments and is applied to the items from all iterables in parallel."
> 
> So map takes the first item(s) of the argument(s), and applies the 
> function to them, followed by the second item(s), and so on.
> 
> In other words:
> 
> def map(function, *iterables):
>  for args in zip(iterables):
>  yield function(*args)
> 
> 
> [1] https://docs.python.org/3/library/functions.html#map
> 
> Come to think of it, this suggests a rather silly alternative "solution":
> 
> map(add_all_elements, *zip(*alist))
> 
> > 
> > In other words, the following should have happened:
> > 
>  add_all_elements (*[1,11,111])
> > My args =  (1, 11, 111)
> > 
> > i = 1
> > BEFORE total = 0
> > AFTER total = 1
> > 
> > i = 11
> > BEFORE total = 1
> > AFTER total = 12
> > 
> > i = 111
> > BEFORE total = 12
> > AFTER total = 123
> > 
> > FINAL total = 123
> > 
> > 123
> > 
> > Again, thanks!
> >

Thanks all, I got it now!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is not working with my "map" usage?

[ROGER GRAYDON CHRISTMAN]

On Sat, Sep 22, 2018, Victor (vhnguy...@yahoo.com) wrote 
Let me use a different input args and display them below.  Basically, I am
hoping to add up all elements of each nested list.  So at first it should start
with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take the 1st
element from each nested list to add up [1,2,3] = 6.   How should it be
corrected?  Thx.
>

>> alist = [[1,11,111], [2,22,222], [3,33,333]]
>
>> list(map(add_all_elements,*alist)
>
>


Trylist(map(add_all_elements, alist)) instead.
If you give a map a single list as a second argument, it will visit eachelement
of that single list (which in this case are the sublists you want).
But that * is replacing the single list with the list contents as separate
arguments,so you are literally telling map to visit all three sublists in
parallel,and it does exactly what you told it to.
The * and ** prefixes really should be avoided as much as possible,unless you
know exactly what you are getting out of them.
Roger ChristmanPennsylvania State University


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple problems with Python 3.7 under Windows 7 Home Premium

[Spencer Graves]

  Thanks very much to all who replied.  This problems was solved as 
follows:  First I downloaded "PyAudio‑0.2.11‑cp37‑cp37m‑win_amd64.whl" 
from "https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyaudio"; as suggested 
by MRAB and Terry Reedy.  Then I ran "python -m pip install 
PyAudio‑0.2.11‑cp37‑cp37m‑win_amd64.whl".  Then I ran the script at 
"https://stackoverflow.com/questions/35344649/reading-input-sound-signal-using-python#35390981";. 
That produced "output.wav" containing 5 seconds of sound recorded from a 
radio connected to "audio in" on my Windows 7 machine.



  Thanks again.
  Spencer Graves


On 2018-09-21 23:33, Terry Reedy wrote:

On 9/21/2018 8:57 PM, MRAB wrote:

On 2018-09-22 01:02, Michael Torrie wrote:

On 09/21/2018 07:22 AM, Spencer Graves wrote:

PYTHON - M PIP INSTALL PYAUDIO


   "python -m pip install pyaudio" stopped with 'error: 
Microsoft visual C++14.0 is required.  Get it with "Microsoft 
Visual C++ Build Tools": 
http://landinghub.visualstudio.com/visual-cpp-build-tools";.


You're going to want to wait until binary wheels of pyaudio for Python
3.7 and Windows 64-bit land in the PyPI repository.  Unless you're
already a visual studio user and have the where with all to build it
from source.  Python 3.7 is a recent release, so I'm not surprised that
some packages don't yet have binary wheels in the repository.


Christoph Gohlke's site appears to have a binary release for Python 3.7:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyaudio


As I remember, he was building binaries for the 300 packages on the 
site well before the 3.7.0 release.




--
https://mail.python.org/mailman/listinfo/python-list

Re: Explicit vararg values

[Michael Torrie]

On 09/16/2018 04:39 PM, Buck Evan wrote:
> The syntax I'm proposing is:
>f(**kwargs={'a': 1, 'b': 2})
> 
> as a synonym of f(a=1, b=2) when an appropriate dictionary is already on
> hand.

But if the kwargs dict already exists you can already unpack it:
f(**kwargs)
or
f(**{'a': 1, 'b': 2})

So I guess I'm unsure of how your proposal differs from this existing
syntax in use.
-- 
https://mail.python.org/mailman/listinfo/python-list