On Wed, Aug 26, 2020 at 9:48 AM Steven D'Aprano <[email protected]>
wrote:
> Demonstration:
>
>
> py> class Dynamic:
> ... def __getitem__(self, arg):
> ... print("original")
> ... type(self).__getitem__ = lambda *args:
> print("replaced")
> ...
> py>
> py> x = Dynamic()
> py> x[0]
> original
> py> x[0]
> replaced
>
I see what you're saying there. So any solution involving `type` of
`object` wrapping a child class method at class creation time should
probably not be considered as a cpython implementation option because of
the dynamic nature of classes. Understood.
> > Sure, it might break some code because somebody, somewhere, has a
> > __getitem__ method written like this:
> >
> > def __getitem__(self, a, b=None, c=None): ...
> [...]
> > But are you really saying there is a very important responsibility not to
> > break that person's code?
>
> Yes.
>
Alright, you've made progress with me on this one. I'm still not totally
convinced such code isn't asking to be broken, but you're right: just
dismissing that as a nonissue isn't correct. It has to be weighed.
> > > Maybe we wouldn't have designed subscripting this way back in Python 1
> > > if we know what we know now, but it works well enough, and we have
> heard
> > > from numpy developers like Stephan Hoyer that this is not a problem
> that
> > > needs fixing. Can we please stop trying to "fix" positional subscripts?
> > >
> >
> > I'm not done trying, sorry. I think the incongruity is a problem.
>
> A problem for whom?
>
> A problem in what way?
>
> PEP 472 goes into detail about the sorts of things people find really
> hard to do with subscripting because of the lack of keywords. Where is
> the discussion by people about the things that are really hard to do
> because of the comma handling in subscripts?
>
Well I will point to Greg Ewin's message from a while ago that I quoted at
the start of this thread:
On Tue, Aug 4, 2020, 2:57 AM Greg Ewing <[email protected]> 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
If we simply add kwarg passing to item dunders, the incongruity between the
subscripting operator and regular function calls will really hinder
people's ability to understand the two. I think most people in these
conversations seem to now agree that this isn't a good enough reason to
exercise the do nothing option, but I think it is a very good reason to
explore other ways of doing it to alleviate that incongruity.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VR6TP5QBLUI7BD6WR4AFGLD7UNGFLX66/
Code of Conduct: http://python.org/psf/codeofconduct/
