On Sat, Sep 26, 2020 at 01:43:18AM -0400, Ricky Teachey wrote:
> On Fri, Sep 25, 2020 at 11:50 PM Steven D'Aprano <st...@pearwood.info>
> wrote:
>
> > TL;DR:
> >
> > 1. We have to pass a sentinel to the setitem dunder if there is no
> > positional index passed. What should that sentinel be?
> >
>
> Isn't there a problem with this starting assumption?
It's not an assumption, it's a conclusion. I can't see any other clean,
and *easy*, way for this to work with setitem. If you can, I'm
listening.
The problem is that there's no simple way to get an optional first
positional argument and mandatory second positional argument:
def __setitem__(self, [index,] value, [*, spam]):
but adding this to the language is out of scope for the PEP. But see
below.
> Say that I have item dunder code of the signature that is common
> today, and I have no interest in providing direct support for kwd args
> in my item dunders. Say also, kwd unpacking is supported.
Okay. Existing code doesn't change.
> If a person unpacks an empty dictionary (something that surely will happen
> occasionally), and a SENTIAL is provided, this poses a pretty good
> possibility to lead to unintended behavior in many cases:
Correct, and well-spotted.
The solution is: *don't do that*.
If you, the caller, do so, that's on your own head. We cannot expect to
protect users from their own errors. Don't insert arbitrary unpacking
into any function or method call, and that includes subscripts, if you
don't know what it will do.
Consider:
obj = {}
kwargs = {'spam': 1}
obj[**kwargs] = value
Right now this is a syntax error, so nobody is doing it. If the PEP is
accepted, it will become a TypeError since dict won't support keywords.
Either way, nobody is going to get into the habit of doing this in
dicts, or lists, or any other class that doesn't support keyword
subscripts.
The only way to get something surprising is:
obj = {}
kwargs = {}
obj[**kwargs] = value
which is equivalent to:
obj[SENTINEL] = value
That's another argument for choosing NotImplemented over None or the
empty tuple. We can't expect subscriptable classes to reject a subscript
of () or None, since these are legitimate keys and have existing uses,
but we can say to class creators "if you care about this, just reject
NotImplemented if it is the subscript".
I expect most classes won't bother. I wouldn't expect `dict` to bother
either.
> Who knows what the effect of c[SENTINEL] will be for so much existing code
> out there? Bugs are surely to be created, aren't they? So a lot of people
> will have to make changes to existing code to handle this with a sentinel.
> This seems like a big ugly problem to me that needs to be avoided.
If this PEP is accepted, it won't magically insert keyword unpacking
into existing code. So it's not going to break existing code.
The only code that might be broken is future code, and even then, we can
can just declare that its not broken, it's working as designed:
obj[**{}] # equivalent to obj[NotImplemented] by definition
If you don't want that, don't do it. I don't think that's the perfect
solution, but I think it is good enough.
> Maybe there's a middle way option that could avoid the particular problem
> outlined above:
>
> # Option 4: do use a sentinel at all, user provides own (if desired)
[...]
> How do we write the dunder item to allow for this? Simple: just require
> that if it is desired to support kwd-only item setting, the writer of the
> code has to provide a default-- ANY default-- to the value argument in
> setitem (and this default will never be used).
Simple to say, but I don't think it will be simple to implement.
Currently, the interpreter treats all methods alike. Given some
arguments, it binds them to the parameters from left to right, then
handles keyword arguments. That's why it can't just skip the first
positional argument (the index) and bind to the second (the value from
the right hand side).
Currently the interpreter doesn't know or care what method is being
called when it packs and unpacks arguments, all method and function
calls get unpacked more or less in the same way: positional arguments
get bound from the left to the right.
If we were willing to add a second set of rules for parameter binding,
we could avoid this problem. Something roughly like this.
For every other function and method:
* bind positional arguments from left to right;
* if too many positional arguments, raise
* handle keyword arguments;
* if too many keyword arguments, or duplicate, raise
* any parameter that doesn't have a value, fetch its default
* if any parameter still doesn't have a value, raise
* call the function
For `__setitem__` only:
* if there is a non-keyword subscript, use the procedure above
* otherwise, bind the RHS value to the second positional parameter
* handle keywords as above
* fetch the default for the first positional argument
* if there is no default, raise
* call the function
I've probably skipped a few steps, but you get the drift. We would need
two distinct ways of packing arguments into parameters, one of which is
specialised for setitem alone.
Is it worth it?
In my opinion, I don't think so, but I'd like to hear from somebody who
knows more about the parameter binding code and can comment on how hard
this would be. I assume it would be tedious but not impossible.
To me it seems like deploying a giant hammer to squash a tiny insect,
but maybe my instinct for the difficulty of this change is way off.
Maybe it's trivially easy and we should just do it :-)
> I suggest the ellipses object as the standard convention:
Ellipsis doesn't make a good choice, because it is heavily used by
numpy. In fact is was specifically added to Python for numpy.
--
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/5AKINF2ABNRXXSSCYNTTTMPOR4MSN26X/
Code of Conduct: http://python.org/psf/codeofconduct/
