On Tue, Aug 25, 2020 at 10:51:42PM -0400, Ricky Teachey wrote:
> > The only way it could tell that would be to inspect *at runtime* the
> > `__setitem__` method. And it would have to do this on every subscript
> > call. Introspection is likely to be slow, possibly very slow. This would
> > make subscripting slow.
> >
>
> Well it would not have to inspect the signature on every subscript call,
Python is a very dynamic language and objects can change their own
methods and even their class at any time, so, yes, it will have to
inspect the signature on every call. Otherwise you are changing
the language execution model.
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
[...]
> People have actually been asking for ways to make subscripting operator act
> more like a function call, so that's not true.
Yes, people have asked for keyword arguments. This proposal doesn't get
us any closer to the feature wanted.
> And it could be useful.
It doesn't give subscripting any additional functionality that doesn't
already exist. It's a purely cosmetic change.
> And
> it does help address the problem of incongruity (though not perfectly)
> between the way a function call handles args and kwargs, and the way the
> subscript operator does it. And it is totally backwards compatible except
> for the case
[...]
So not actually totally backwards compatible.
Please stop calling things "totally backwards compatible" if they aren't
totally backwards compatible. If you change the behaviour of existing
legal code, it's not backwards compatible.
> > 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?
[...]
> Remember: the signature dependent semantics proposal is to maintain
> backwards compatibility, 100%, for any code that has been following the
> very clear intent of the item dunder methods.
The Python language doesn't follow the rule "Do what we intend you to
do", it follows the rule "this is how the language works, do whatever
the language allows".
PEP 5 doesn't mention the word "intent" and doesn't say "its okay to
break people's code if they are using Python in ways we don't like".
You don't get to say that breaking legal code that works today is okay
because it doesn't follow "the intent". It's still a breaking change and
you have to convince the Steering Council that breaking other people's
code for the sake of fixing an incongruity is worthwhile.
Imagine it was code *you* relied on that broke, and you no longer had
the source code for it, it was a library compiled away in a .pyc file
and the company that distributed it has gone broke and the source code
lost, and replacing that library is going to cost your business a year
of time and a hundred thousand dollars in development costs.
But that's okay, because an incongruity that makes no difference to
anyone's code has been fixed.
Now maybe you can convince the Steering Council that this is a clear win
for the broader community. We do break backwards compatibility,
sometimes, if the risks are small enough and the benefits large enough.
But be honest about what you are doing.
> 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.
--
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/B3ZY3BS6DHB23HNVERKXYVGXB2TSM56P/
Code of Conduct: http://python.org/psf/codeofconduct/
