It's been a while since this was posted, but a thought: Here's an idea. At present both of > > d[1:2] >> d[1:2, 3:4, 5, 6] >> are valid syntax, but neither of >> d[(1:2)] >> d[(1:2, 3:4, 5, 6)] >> are valid syntax. This is, I think, a bit of an anomaly. >> > indeed -- it's been very much a part of this conversation that:
thing[i,j,k] is exactly equivalent to thing[(i,j,k)] because the tuple is "created by" the parentheses. That is, nothing special is going on inside the brackets. After all: In [4]: x = 1, 2, 3 In [5]: y = (1, 2, 3) In [6]: x == y Out[6]: True and thing[1:2, 3:4] does create a tuple, and pass it on to the __*item__ dunder. and thing[slice(1,2), slice(1,2)] is exactly equivalent to thing[(slice(1,2), slice(1,2))] (or course) So the only missing piece here is that that slice syntax can only be used directly inside the square brackets. This, of course, has been the case for the history of Python, and it's worked pretty well, but I do think it becomes more of an issue/constraint if/when we add complexity to the indexing -- e.g. adding keyword arguments. And there are other reasons to allow slice syntax elsewhere anyway. As the colon is used elsewhere in Python, it's not as simple as simply allowing slice syntax as a legal expression that can be used everywhere any other expression can be used. I know I haven't thought it out yet, but I would be supportive of a PEP to extend the "domains" in which slice syntax can be used, if someone does have the energy to think it out and write a PEP. I do think it should be completely separate from PEP 637, but if PEP 637, or something like it, were accepted, it would provide additional motivation for this idea. I suggest a PEP that extended the syntax to allow >> (1:2) >> (1:2, 3:4, 5, 6) >> to be expressions (to be used as function arguments, with the existing >> item access semantics). >> > One adjustment -- if, e.g. (1:2) becomes a legal expression for creating a slice, then we're done -- nothing special about function arguments, or item access semantics -- it would simply be a "literal" for a slice object, and could be used anywhere any other expression could be used, and would mean whatever a slice "means" in that context. -CHB PS: It's hard to imagine this hasn't been proposed in the past, so the next step is to do the research and find out if indeed it has, and if so, why it didn't happen. A quick googling reveals the rejected PEP 204 https://www.python.org/dev/peps/pep-0204/ which proposed a "range literal", which used slice syntax to create a range -- but that's something different (and, indeed, range objects are different than they were back then as well) So it doesn't look like this ever made it to a PEP, but it probably has been discussed on this list ... -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/HXPKPPG6HSBUIRMXI7MQRS4ORUBH6MYP/ Code of Conduct: http://python.org/psf/codeofconduct/
