On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey <ri...@teachey.org> wrote:
> The following comment is from the thread about adding kwd arg support to
> the square bracket operator (eg, `Vec = Dict[i=float, j=float]`).
>
> On Tue, Aug 4, 2020, 2:57 AM Greg Ewing <greg.ew...@canterbury.ac.nz>
> wrote:
>
> On 4/08/20 1:16 pm, Steven D'Aprano wrote:
> > Why would we want to even consider a new approach to handling keyword
> > arguments which applies only to three dunder methods, `__getitem__`,
> > `__setitem__` and `__delitem__`, instead of handling keyword arguments
> > in the same way that every other method handles them?
>
> These methods are already kind of screwy in that they don't
> handle *positional* arguments in the usual way -- packing them
> into a tuple instead of passing them as individual arguments.
>
> I think this is messing up everyone's intuition on how indexing
> should be extended to incorporate keyword args, or even whether
> this should be done at all.
>
> --
> Greg
>
>
> So here is the main question of this thread:
>
> Is there really not a backwards compatible, creative way a transition to
> positional args from a tuple in the item dunders could not be accomplished?
>
> It's not my intention to champion any specific idea here, just creating a
> specific space for ideas to be suggested and mulled over.
>
> There could be several reasons for changing the item dunder signatures.
> The immediate reason is making the intuition around how to add kwd arg
> support to square brackets more obvious and sane.
>
> A second reason is it might be more intuitive for users who have to learn
> and remember that multiple arguments to [ ] get packed into a tuple, but
> this doesn't happen anywhere else.
>
My main issue with this is that, in my opinion, dunders are not something a
beginner should be messing with anyway. By the time someone is experienced
enough to start working on this, they are also experienced enough to
understand that special cases like this exist for historical reasons.
> Another reason: it could make writing code for specialized libraries that
> tend to abuse (for the good of us all!) item dunders, like pandas, much
> easier. Right now such libraries have to rely on their own efforts to break
> up a key:
>
> def __getitem__(self, key):
> try:
> k1, k2 = key
> except TypeError:
> raise TypeError("two tuple key required")
>
> But for regular function calls (as opposed to item getting) we get to
> write our signature however we want and rely on the language to handle all
> of this for us:
>
> def f(k1, k2):
> # no worries about parsing out the arguments
>
But this is still a pretty simple piece of code. Is it worth having
everyone start over from scratch to avoid dealing with 4 lines of code?
Especially since knowing the number of indices ahead of time is a special
case for a small number of projects like pandas. In most cases, the number
of indices cannot be known until runtime, so this would provide no
practical benefit for most projects.
> -----------
>
> One idea: change the "real" names of the dunders. Give `type` default
> versions of the new dunders that direct the call to the old dunder names.
>
> The new get and del dunders would have behavior and signatures like (I am
> including **__kwargs since that could be an option in the future) :
>
> def __getx__(self, /, *__key, **__kwargs):
> return self.__getitem__(__key, **__kwargs)
>
> def __delx__(self, /,, *__key, **__kwargs):
> del self.__delitem__(__key, **__kwargs)
>
> However the set dunder signature would be a problem, because to mirror the
> current behavior we end up writing what is now a syntax error:
>
> def __setx__(self, /, *__key, __value, **__kwargs):
> self.__setitem__(__key, __value, **__kwargs)
>
> The intended meaning above would be that the last positional argument gets
> assigned to __value. Maybe someone could suggest a way to fix this.
>
The simplest way would be to put "value" first:
def __setx__(self, __value, /, *__key, **__kwargs):
_______________________________________________
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/44KYEFMSNDHBJGWCNLMR2OJI3YTV7OUH/
Code of Conduct: http://python.org/psf/codeofconduct/
