On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote:
> >So if you want to accept keywords, you just add keywords to your
> >existing dunder method. If you don't want them, don't add them. We don't
> >need a new dunder just for the sake of keywords.
>
> Nobody disputes that it *could* be made to work that way. But I'm
> not convinced that it's the *best* way for it to work. The killer
> argument in my mind is what you would have to do to make an object
> where all of the following are equivalent:
>
> a[17, 42]
> a[time = 17, money = 42]
> a[money = 42, time = 17]
I don't think that something like that is exactly the intended use-case
for the feature, at least not intended by *me*, that looks more like it
should be a function API. But I'm sure people will want to do it, so
we should allow it even if it is an (ever-so-slight) abuse of
subscript notation.
(But I note that one of the PEP co-authors, Joseph Martinot-Lagarde, has
now suggested that we bypass this question by simply requiring an index,
always.)
> With a fresh new dunder, it's dead simple:
>
> def __getindex__(self, time, money):
> ...
Okay, that's an advantage if you're writing this sort of code. I'm not
sure its a big enough advantage to require such changes, new dunders,
new byte codes, etc, but YMMV.
[...]
> >But type slots are expensive in other ways. Every new type slot
> >increases the size of objects, and I've seen proposals for new dunders
> >knocked back for that reason, so presumably the people care about the
> >C-level care about the increase in memory and complexity from adding new
> >type slots.
>
> It doesn't seem like a serious problem to me. Type objects are
> typically created once at program startup, and they're already
> quite big. If it's really a concern, the new slots could be put
> in a substructure, so the type object would only be bigger by
> one pointer if they weren't being used.
*shrug* I don't know enough about type slots, except I am confident that
I have seen dunders rejected because it would require adding new type
slots. But maybe I have the details wrong and am thinking of something
else.
> Another possibility would be to have them share the slots for
> the existing methods, with flags indicating which variant is
> being used for each one. A given type is only going to need
> either __getindex__ or __getitem__, etc., not both.
In which case, why do we need new names for the methods? Effectively
they're the same method, just with different behaviour and a different
name, but since you can only use one even if you define both, why would
you define both?
I would expect it is less confusing and error prone to just say
"Starting in version 3.10 subscript parsing changes and item dunders
should change their signature ..." than to have two sets of dunders,
especially when the names are so similar that invariably people will
typo the names:
class X:
def __getindex__(self, ...):
# later
def __setitem__(self, ...): # oops
I'd rather a conditional:
class X:
if sys.version_info >= (3, 10):
# New signatures
def __getitem__(self, ...):
else:
# Old signatures
Or conditionally inherit the dunders from a mixin:
if sys.version_info >= (3, 10):
from this_is_the_future import item_mixin:
else:
from legacy import item_mixin
class X(item_mixin):
pass
Having to remember which name goes with which version is going to be
annoying and tricky, especially since for many simple cases like lists
and dicts the getitem and getindex versions will be identical.
[...]
> >5. alternatively, we could leave the existing C-level sequence and
> > mapping objects alone, and create *four* brand new C-level objects:
> >
> > - a sequence object that supports only the new index protocol;
> > - a sequence object that supports both index and item protocols;
> > - and likewise two new mapping objects.
>
> I don't follow this one. How can there be both old and new
> protocols without adding new dunder methods?
I didn't say anything about inventing new protocols without new dunders.
All five of my alternatives were under the assumption that the new
protocol and new dunders was going ahead.
But as I mention above, if we did introduce this, I'd rather we keep the
dunders and change the name rather than introduce confusable names.
--
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/XQ4Y6DB2WE3HPY7D35BAU3AR2TWESGXK/
Code of Conduct: http://python.org/psf/codeofconduct/
