On Sat, Aug 29, 2020 at 12:50:15AM -0400, Ricky Teachey wrote:
> I was really trying to explain the semantics multiple times but as I look
> over my messages your criticism is correct, I was throwing out too many
> detailed examples rather than focusing on the idea.
Also there are so many different proposals being thrown out at the same
time, by different people, that it is difficult to keep track of what is
what.
> For your benefit- since
> my explanations weren't sufficient- I wrote a bunch of admittedly
> junkie code, which is sometimes easier to understand (even if it is buggy)
> than English, in an attempt to showcase the idea more clearly.
Coders often say that a line of code says more than ten lines of
explanation, and often that's true, but sometimes, especially when
dealing with a new proposal for functionality that doesn't actually
exist yet, a line of explanation is better than a hundred lines of code
:-)
[...]
> > The status quo is that the subscript is passed as either a single value,
> > or a tuple, not multiple arguments. If that *parsing rule* remains in
> > place, then these two calls are indistinguishable:
> >
> > obj[spam, eggs]
> > obj[(spam, eggs)]
> >
> > and your subscript dunder will only receive a single argument because
> > that's what the parser sees. So you need to change the parser rule.
> >
>
> Yes I've made this observation myself in a couple different replies and I
> agree it's a problem. Greg Ewing (again!) had a helpful comment about it,
> perhaps he is correct:
[... snip Greg's suggestion ...]
> However, I'm not sure whether it's necessary to go that far. The important
> thing isn't to make the indexing syntax exactly match function call syntax,
> it's to pass multiple indexes as positional arguments to __getindex__. So
> I'd be fine with having to write a[(1,)] to get a one-element tuple in both
> the old and new cases.
But the problem is that this is a change in behaviour, which is not
backwards compatible and will break old code.
You might be happy with writing `a[(1,)]` to get a tuple but there is
almost certainly a ton of existing code that is already writing `a[1,]`
to get a tuple, and I don't think you are volunteering to go out and fix
it all :-)
So we have some choices:
(1) No breaking old code at all. In that case your proposal is dead in
the water, or we need a complicated (maybe fragile?) techical solution
that fixes it, as suggested by Greg. (Assuming it is practical.)
The more complicated the fix, the less attractive the proposal becomes.
(2) We're okay with breaking code but need a future directive. In which
case, why bother with this signature dunder? It's no longer
necessary.
(3) It's only a *little* breakage, so just go ahead and make the change
and don't worry about breaking old classes.
I would expect that the Steering Council would only agree if this little
breakage was balanced by a *large* benefit, and I'm not seeing the large
benefit given that we've heard from a numpy developer that the status
quo re positional arguments is no burden, and I don't think anyone from
the xarray or pandas projects have disagreed.
So it seems to me that this "change the parsing of commas" is being
driven by people who aren't actually affected by the change, and the
people who are affected are saying "we don't need this".
(Which is very different from the original part of the proposal, namely
adding *keywords*.)
> > Your subscript preprocessor would allow the coder to stick spam and eggs
> > into a tuple and pass it on, but it also returns a dict so the getitem
> > dunder still needs to be re-written to accept `**kwargs` and check that
> > it's empty, so you're adding more, not less, work.
>
>
> No, that's not right. The kwargs mapping included in the return by the
> preprocessor gets unpacked in the item dunder call. An unpacked empty dict
> in an existing item dunder (without kwargs support) creates no error at all.
Yes, you're right, sorry.
> > Okay, let's make the interpreter smarter: it parses spam, eggs as two
> > arguments, and then sees that there is no subscript dunder, so it drops
> > back to "legacy mode", and assembles spam and eggs into a tuple before
> > passing it on to the item getter.
> >
>
> That's one way to think about it. Another way to think about it is, there
> is an existing preprocessing function in cpython, today -- and that function
> is currently not exposed for external use, and it currently gets passed
> (spam, eggs) as a tuple and silently sends that tuple on to the item
> dunders:
So this preprocessor is a do-nothing identity function that does nothing
and doesn't actually get called by anything or even exist.
I don't think it is a helpful argument to invent non-existent pre-
processors that do nothing.
[...]
> if len(args) == 1, and if it is, it returns args[0]. Otherwise, it returns
> just args (a tuple). I believe that should replicate the behavior we have
> now.
So if I currently do this:
my_tuple = (1,)
obj[obj]
your updated preprocessor will pass just 1, not the tuple, on to the
item getter. That's not the current behaviour.
> > This sort of change in behaviour is exactly why the future mechanism was
> > invented. If it is desirable to change subscripting to pass multiple
> > positional arguments, then we should use that, not complicated jerry-
> > rigged "Do What I Mean" cunning plans that fail to Do What I Meant.
> >
>
> Cool. I'm interested.
If we decide that this change in behaviour is required, we define a new
future directive that simply changes the way subscripts are parsed.
People who want to use the new behaviour include that future directive
at the top of their module to get the new behaviour. Those who don't,
don't, and nothing changes.
Eventually the change in behaviour becomes standard, but that could be
put off for two or four releases.
https://docs.python.org/3/reference/simple_stmts.html#future
https://docs.python.org/3/library/__future__.html
--
Steve
_______________________________________________
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/3RPNTG3KKTDBOBU25FUTRAGPEJ76765I/
Code of Conduct: http://python.org/psf/codeofconduct/
