On Tue, Oct 8, 2019 at 2:03 PM Steven D'Aprano <st...@pearwood.info> wrote:
> On Tue, Oct 08, 2019 at 12:55:40PM -0400, Todd wrote: > > > > da.isel(space=0, time=slice(None, 2))[...] = spam > > > > > > With this syntax this could be changed to: > > > > > > da[space=0, time=:2] = spam > > > > > Anders: > > > I must have missed something... when did the proposal we're discussing > > > start allowing : there? > > Todd: > > Why wouldn't it? > > Wrong question. New features are not "default accept", we accept them > unless there is a strong reason to reject them. They are "default > reject", we reject them unless there is a good reason to accept them. So > the right question is, why should we accept colons there? > My point, which I could have made clearer, is that converting colons to slices is part of how __getitem__ works. So __getitem__ would not really be supporting keyword arguments in the same way it supports positional arguments unless it was supporting the same syntax. This would be adding additional restrictions on the keyword syntax relative to the positional one rather than making the two equivalent. I assumed, I guess wrongly, that the general assumption would be that a new extension to the syntax would behave consistently with whatever it is extending unless there was some specific reason for it not to. > This is a proposal for adding keyword args to subscripting, not > colon-syntax for slice objects inside arbitrary expressions. If you wish > to propose that, you can propose it separately. > No, if you read the OP, this is a proposal for adding keyword arguments to __getitem__. At least in my mind, __getitem__ would not have full support for keyword arguments if it didn't support the same syntax as positional arguments, since everywhere else in Python you can do the same things with either as far as I am aware. As far as I can tell no one ever mentioned limiting just to subscripts, so I assumed such limitations were not important. You apparently assumed differently. And I don't think splitting that off into a separate thread would be productive. The issue is tightly linked in with this one, since the decision would have to be made in any implementation whether the positional or keyword syntaxes would be equivalent, or if additional restrictions are to be imposed on a keyword-based syntax. That decision would make an enormous impact on how useful this new syntax would be. > But for the record, here is one reason why we probably should not allow > `time=:2` as syntactic sugar for `time=slice(None, 2)`. > > It is confusing as hell. When I saw this > > da[space=0, time=:2] > > I read it as a slice: > > da[ slice( (space=0, time=), 2, None) ] > > and thought "That must be a typo, because the time keyword > doesn't have a value." > > I am really sorry, but I am really having a hard time understanding your reasoning here. Can you explaining how you came up with that result? I am not sure why you would think keyword arguments would work so completely differently than positional ones in this context. Why should that parse to a single slice when da[0, :2] parses to a slice and an index? > And combining slice syntax with keywords in the same call is a recipe > for over-complicated, confusing subscripts, which is why Caleb initially > suggested you can use one, or the other, but not both. > I have looked through the whole thread and I can't see anyone, especially not Caleb, saying that. Caleb said we shouldn't mix positional with keyword arguments, is that what you are thinking of?
_______________________________________________ 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/VCQJJ42STXKFHXKOVYVGIUNIKDEIW36N/ Code of Conduct: http://python.org/psf/codeofconduct/
