> I think it might be better if it actually passed them as keyword
arguments.
If only keyword arguments are passed what happens to the positional index?
Is it the empty tuple?
Currently subscript with no index (`dict()[]`) is a syntax error should it
continue to be?
> Also, I think there are user implementations that accept any iterable,
whether to treat it as a tuple or as an array-like, and a dict is an
iterable of its keys, so it might do the wrong thing rather than raising at
all.
I had not thought about this. I have a lot of code in the form:
```
if not isinstance(key, iterable):
key = key,
# do stuff assuming key is an iterable
```
Which would have very strange behavior if a dict was passed.
On Mon, Oct 7, 2019 at 2:44 PM Christopher Barker <python...@gmail.com>
wrote:
>
> Are you aware of PEP 472 https://www.python.org/dev/peps/pep-0472 ?
>>
>
> That is indeed the same idea, though perhaps the details are a bit
> different.
>
> This example from the PEP:
>
> gridValues[x=3, y=5, z=8]
>
> Makes me wonder:
>
> Should that yield the same results as:
>
> gridValues[3,5,8]
>
> Much like positional and keyword arguments work on function calls?
>
> I suppose that would be up to the implementation, as __getitem__ doesn’t
> currently provide much help with parsing out what’s in there, other than
> making slice objects.
>
> But if something like this did go forward, it would be nice to provide
> utilities, maybe built in, that would parse and sort out the “arguments”,
> similar to function calls.
>
> -CHB
>
>
> Maybe you have something different in mind, but for me your idea looks
>> pretty the same. While the PEP 472 is in Rejected, Abandoned section, I
>> do not remember any serious criticism of this idea. It’s just that the
>> authors of that proposal lost interest and it did not receive further
>> progress. And in this regard, over time, it was abandoned.
>>
>> with kind regards,
>> -gdg
>>
>> пт, 4 окт. 2019 г. в 23:01, Caleb Donovick <donov...@cs.stanford.edu>:
>>
>>> While there is no restriction on passing dicts to getitem. Doing so
>>> tends to be a bit ugly. I have two main use cases in mind for this syntax.
>>>
>>> The first and perhaps the most obvious, is doing relational queries.
>>> ```
>>> where_x_1 = db[x=1]
>>> ```
>>> is more beautiful than
>>> ```
>>> where_x_1 = db[dict(x=1)]
>>> where_x_1 = db[{'x': 1}]
>>> # or by abusing slices
>>> where_x_1 = db['x':1]
>>> # or in the style of Pandas
>>> where_x_1 = db[db['x'] == 1]
>>> ```
>>>
>>> Beyond relational queries my own personal use case is a shorthand for
>>> dataclasses / protocols.
>>> ```
>>> foo: ProtoRecord[x=int, y=int] = DataRecord[x=int, y=int](0, 1)
>>> ```
>>> where `DataRecord[field0=T0, ..., fieldk=Tk]` generates
>>> ```
>>> @dataclass
>>> class Record:
>>> field0: T0
>>> ...
>>> fieldk: Tk
>>> ```
>>> and `ProtoRecord[field0=T0, ..., fieldk=Tk]` generates a similar
>>> protocol.
>>>
>>> Allowing key value pairs in geitem need not change the interface of
>>> getitem. All the key value pairs could be collected as a dict and passed
>>> to getitem as the index. Similar to how the all the positional arguments
>>> are gather into a single tuple.
>>> ```
>>> class Foo:
>>> def __getitem__(self, idx):
>>> print(idx)
>>>
>>> f = Foo()
>>> f[x=1, y=2] # {'x': 1, 'y': 2}
>>> ```
>>> This would make any legacy code using normal dicts as keys (I don't know
>>> how prevalent that is) automatically work with the new syntax.
>>>
>>> There doesn't necessarily need to be support for mixing of tuple based
>>> indexing and keyword indexing. i.e.
>>> ```
>>> obj[0, x=1] # SyntaxError
>>> ```
>>>
>>> I don't really know anything about parsers but I think the grammar could
>>> be extended without issue with the following rule:
>>> ```
>>> subscriptlist: ... | kwargsubscript (',' kwargsubscript )* [',']
>>> kwargsubscript: NAME '=' test
>>> ```
>>> if `NAME '=' test` would result in ambiguity similar to argument it
>>> could be `test '=' test` with a block in ast.c
>>>
>>>
>>> - Caleb Donovick
>>> _______________________________________________
>>> 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/EUGDRTRFIY36K4RM3QRR52CKCI7MIR2M/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> _______________________________________________
>> 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/XPQC6AIX2REI5W6EKCRRI7UEGJWVEOC6/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> Christopher Barker, PhD
>
> 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/OL6FKBGJFAFQK2MFECWWD7EARZPJUMK6/
Code of Conduct: http://python.org/psf/codeofconduct/
