On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote:
> In this fashion have you considering having keyword only indices, that is
> to only allow either obj[1, 2] or obj[row=1, col=2] (if the class supports
> it), and disallow mixing positional and keyword indices, meaning obj[1,
> col=2] would be a SyntaxError.
That would severely reduce the usefulness of this feature for me,
probably by 80 or 90%, and possibly make it useless for xarray and
pandas.
(I don't speak for the pandas or xarray devs, I'm happy to be
corrected.)
But for my own code, my primary use-case is to have a mixed positional
index and keyword arguments. I would *much* rather give up keyword-only
subscripting. Keyword-only subscripting would be a convenience and a
useful feature, but it's mixed subscripting that I am really hungry for.
Hmmm, that's a thought... maybe we should just prohibit keyword-only
calls for now? People who want a "keyword only" call can provide their
own "do nothing" sentinel as the index.
For my own purposes, I could easily adapt the keyword-only cases to use
None as an explicit sentinal:
matrix[row=1] # Nice to have.
matrix[None, row=1] # Good enough for my purposes.
so for my own purposes, if keyword-only is too hard, I'd be happy to
drop it out of the PEP and require an explicit index.
> If we followed that path, then adding a new set of dunders may not be that
> problematic as the use case would be slightly different than the current
> semantics.
I don't see how "the use case is different" solves the problems with
adding new dunders.
Adding new dunders is problematic because:
* they probably require new C level slots in objects, increasing
their size;
* and the added complexity and likelihood of confusion for
developers. Do I write `__getitem__` or `__getindex__`?
We had this back in Python 1 and 2 days with `__*item__` and
`__*slice__` dunders and moved away from that, let's not revert back to
that design if we can avoid it.
> I also agree with Stefano that something like a[1, 2, unit="meters"] feels
> really odd,
Could be because of the misspelling of metres (unit of measurement)
versus meters (things you read data from) *wink*
Without knowing what the object `a` represents, or what the meaning of
the subscript is, how can we possibly judge whether this is a reasonable
use of a keyword subscript or not?
Stefano wrote:
> > a[1, 2, unit="meters"]
> >
> > makes me feel uncomfortable, although I might learn to accept it. In
> > particular, the above case becomes kind of odd when you use it for
> > setitem and delitem
> >
> > a[1, 2, unit="meters"] = 3
> >
> > what does this mean? convert 3 to meters and store the value in a?
You made the example up, so you should know what it means :-)
I don't even know what `a[1, 2, unit="meters"]` means since we don't
know what `a` is.
> > Then why isn't the unit close to 3, as in
> >
> > a[1,2] = 3 * meters
> >
> > and what about this one?
> >
> > del a[1, 2, unit="meters"] # and this one?
In my own use-case, all three get/set/delete operations will support the
same keywords, but just because we syntactically allow subscripts
doesn't make it mandatory to use them identically useful for all three
opperations in all cases. There is no need for the dunder to support a
keyword that makes no sense for that dunder.
For example, suppose we had a sequence-like mapping that supports this
get operation:
table[index, default="index out of range"]
That doesn't mean that table has to support the same keyword
when setting or deleting, it can use different keywords that make no
sense when getting:
table = Table([1, 2, 3, 4])
table[10, fill=-1] = 5
print(table)
# => [1, 2, 3, 4, -1, -1, -1, -1, -1, -1, 5]
del table[index, errors="ignore"] # Silence error if out of range.
There's no requirement that the three get/set/delete operations have to
use the same keywords, or any keywords at all, only that they *could* if
required.
*Allowing* symmetry between the three options is a must; *requiring*
symmetry between them is not.
--
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/OEBA3N5UXSTJL3QIQMQIHQ5DOBTAYETL/
Code of Conduct: http://python.org/psf/codeofconduct/
