On Sat, 29 Aug 2020 at 15:12, Ricky Teachey <ri...@teachey.org> wrote:
>
> But if we want to have the same behavior without supporting function
> style syntax, we will have to write code like this:
>
> MISSING = object()
>
> def __getitem__(self, key, x=MISSING, y=MISSING):
> if x is MISSING and y is MISSING::
> x, y = key
> if x is missing:
> x, = key
> if y is MISSING:
> y, = key
>
> And probably that code I just wrote has bugs. And it gets more
> complicated if we want to have more arguments than just two. And
> even more complicated if we want some of the arguments to be
> positional only or any other combination of things.
>
> This is code you would not have to write if we could do this instead
> with a new dunder or subscript processor:
>
> def __getx__(self, x, y): ...
>
> And these all just work:
>
> q[1, 2]
> q[1, y=2]
> q[y=2, x=1]
>
> 1 is assigned to x and 2 is assigned to y in all of these for both
> versions, but the second certain requires not parsing of parameters.
> Python does it for us. That's a lot of easily available flexibility.
I was partway through writing a message outlining this very point.
It's all well and good stating that named indices are an intended use
case (as in the PEP), but in cases where named indices would be useful
they presumably aren't currently being used (abuses of slice notation
notwithstanding). As such, if a variant of PEP 472 were implemented,
code that would benefit from named indices must still find a way to
support 'anonymous' indices for backwards compatibility.
I believe the code to implement that ought to be much more obvious
(both to the author and to readers) if 'anonymous' and named indices
were simply handled as positional and keyword arguments, rather than
manually parsing and validating the allowable combinations of indices.
That being said, it should be noted that even if there are no new
dunders, you don't necessarily need to parse the subscripts manually.
You could still take advantage of python's function-argument parsing
via something resembling the following:
```python
def _parse_subscripts(self, /, x, y):
return x, y
def __getitem__(self, item=MISSING, /, **kwargs):
if item is MISSING:
args = ()
elif isintance(item, tuple):
args = item
else:
args = (item,)
x, y = self._parse_subscripts(*args, **kwargs)
return do_stuff(x, y)
```
However that's still not exactly obvious, as the 'true' signature has
been moved away from `__getitem__`, to an arbitrarily named
(non-dunder) method.
A major difference between the above, and the case where we had one or
more new dunders, is that of introspection: new dunders would mean
that there would be a 'blessed' method whose signature exactly defines
the accepted subscripts. That would be useful in terms of
documentation and could be used to implement parameter completion
within subscripts.
---
Theoretically the signature could instead be defined in terms of
`typing.overload`s, something like the following (assuming x & y are
integers):
```python
@overload
def __getitem__(self, item: tuple[int, int], /): ...
@overload
def __getitem__(self, item: int, /, *, y: int): ...
@overload
def __getitem__(self, /, *, x: int, y: int): ...
def __getitem__(self, item=MISSING, /, **kwargs):
# actual implementation, as above
...
```
However that is incredibly verbose compared to the signature of any
new dunder, and would only grow worse with a greater number of keyword
subscripts.
_______________________________________________
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/RKRMT4XYTXH57VBLMY772CRC2DXFTDVX/
Code of Conduct: http://python.org/psf/codeofconduct/
