On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote:
> On Wed, Aug 26, 2020 at 11:19 AM Steven D'Aprano <st...@pearwood.info>
> wrote:
>
> > On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote:
> >
> > > But I have to say that I think this latest is a fantastic idea, and when
> > > Jonathan presented it to me it was very surprising that I had not seen it
> > > presented by anyone else yet. I think it solves a ton of problems,
> >
> > Such as?
> >
>
> It creates a language supported way for the creator of the class to decide
> how to interpret the contents inside a subscript operation.
We already have that: `__getitem__`.
> This is a
> problem because disagreement over this matter is a large part of the reason
> PEP 472-- the spirit of which I support-- has been held up.
As I see it, the disagreement comes about from two main areas:
- People who want to bake into the language semantics which solve a tiny
niche problem ("what if I want to treat keyword:argument pairs as
keys?"), making the common use-cases much harder to solve.
- And people trying to over-engineer some complicated solution to
something that isn't actually a problem: the supposed inconsistency
between subscripts and function calls.
The disagreement isn't from people arguing about how your class should
interpret the keywords. That isn't holding up the PEP.
Interpreting the keywords is easy: interpret them however you want.
Python doesn't tell you what the keywords mean, it just hands them to
your method.
> It greatly
> alleviates (though not perfectly-- see the end of this message) the
> incongruity between how the indexing operator behaves and function calls
> behave. As explained by Jonathan Fine, it adds flexibility
What flexibility is added that `__getitem__` doesn't already provide?
> and smoothes out
> the differences the different paradigms of subscript operations: sequences,
> and mappings.
Won't sequences and mappings still call the same dunder method?
> And it opens up opportunities for other paradigms to be
> created, the most prominent example of which is type-hint creation
> shortcuts, like:
>
> Vector = Dict[i=float, j=float]
That's not a paradigm. That's just an application of the feature.
*Type-hints* was a major change to the Python's language paradigm. This
is just a (potential) nice syntax that allows a concise but readable
type-hint.
https://en.wikipedia.org/wiki/Paradigm
[...]
> > > For example: if this proposal were already in place and PEP 472 were to
> > > continue to be held up because of terrorists like me ;) *, one could have
> > > written this translation function and PEP-472-ify their classes already:
> > >
> > > def yay_kwargs(self, *args, **kwargs):
> > > return self.__getitem__(args, **kwargs)
> >
> > You're calling the `__getitem__` dunder with arbitrary keyword
> > arguments. Are you the same Ricky Teachey who just suggested that we
> > should be free to break code that uses `__getitem__` methods that don't
> > obey the intent that they have only a single parameter and no keywords?
> >
>
> I am talking hypothetically-- if this proposal were already in place (which
> *includes* passing kwargs to the *new dunder* rather than passing them to
> the existing item dunders by default), you could write code like yay_kwargs
> today, even if the default way the language behaves did not change.
You're suggesting that if subscript keywords were permitted, rather than
having the keywords passed directly to `__getitem__` where they are
wanted, the interpreter should pass them to another method and then that
method could pass them to `__getitem__`.
Or we could just pass them directly into `__getitem__`, as requested.
How does the interpreter know to call yay_kwargs rather than some other
method?
> In that universe, if I wrote this:
>
> class C:
> def __getitem__(self, key):
> print(key)
>
> ...and tried to do this:
>
> >>> C()[a=1]
> SomeError
>
> ...*in that universe*, without PEP 472, the language will STILL, by
> default, give an error as it does today (though it probably would no longer
> be a SyntaxError).
That is a remarkably unenlightening example.
There's no sign of what your new method is or what it does. There's an
error, but you don't know what it is except it "probably" won't be a
syntax error, so you don't even know if this error is detected at
compile time or runtime.
You say PEP 472 is not accepted, but maybe it is accepted since keyword
subscripts are possibly not a syntax error, or maybe they are still a
syntax error. Who knows? Not me, that's for sure.
I feel like I'm trying to nail jelly to a wall, trying to understand
your proposal. Every time I ask a question, it seems to twist and mutate
and become something else.
And how does this relate to Jonathan's idea of "signature dependent
semantics" which you were singing the praises of, but seems to have
nothing to do with what you are describing now.
[...]
> We could make the dunder to accept the target dunder method name as a
> parameter. This way there is only a single new dunder, rather than 3.
Or we could have no new dunders at all, and just pass the keywords to
the appropriate, and existing, `__*item__` methods.
I'm going to ignore the business about `__subscript__` because you seem
to have backed away from it in a later email, except for one relatively
minor point. You proposed this:
> No CODE CALLS
> 1. q[1] q.__subscript__("__getitem__", 1)
> 2. q[1,] q.__subscript__("__getitem__", 1)
> 3. q[(1,)] q.__subscript__("__getitem__", 1)
But that's not what subscripting does now. If you use `q[1,]` the
getitem method gets the tuple (1,), not the int 1. So if you're serious
about that, it's a breaking change.
py> "abcd"[1]
'b'
py> "abcd"[1,]
TypeError: string indices must be integers
--
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/F343PGE3WGYD7MRKYRLCQKBNKREZF5NZ/
Code of Conduct: http://python.org/psf/codeofconduct/
