Suggested feature: slice syntax within tuples (or even more generally)?

Andrew Robinson andrew3 at
Mon Feb 25 02:10:26 CET 2013

On 02/14/2013 05:23 AM, Terry Reedy wrote:
> On 2/13/2013 2:00 PM, stephenwlin at wrote:
>> Hello,
>> Would it be feasible to modify the Python grammar to allow ':' to 
>> generate slice objects everywhere rather than just indexers and 
>> top-level tuples of indexers?
>> Right now in Py2.7, Py3.3:
>>      "obj[:,2]" yields "obj[slice(None),2]"
>> but
>>      "obj[(:,1),2]" is an error, instead of "obj[(slice(None), 1), 2]"
>> Also, more generally, you could imagine this working in (almost?) any 
>> expression without ambiguity:
>>      "a = (1:2)" could yield "a = slice(1,2)"
I've read through the whole of the subject, and the answer is no, 
although I think allowing it in (::) is a *very* good idea, including as 
a replacement for range or xrange.

for i in s:
for i in (1:2:3) :
and I really don't even mind, for i in s[a]:
or even a[1,2,5,11] where the indicies are equivalent to *sequence* 
other than xrange.
Python evaluates right to left; this is semantically an iterator giving 

This is not a new idea: eg: 2002. (which is still status OPEN).

The python code in c-python is quite bloated; consolidating some of it, 
making it more consistent, and raising other parts to a high level 
language, I think are the way of the future.
I'm a fan of this to the point of implementing Python without a parser 
in the core, but as a script implicitly loaded *on demand*; much simpler 
and easier to modify at will and reuse mixed legacy code...

On Travis Oliphant:  I agree...
The numpy communities desire for readable slice functionality (and 
matrix compatible/intuitive code) is only going to get stronger with 
time.  Python is attractive to the scientific community, but legacy 
biased against clean matrix math...
PEP 225's... desire for readability is important to me too ... even if a 
fork happens.
( An aside: I hate line noise, and fights, so UTF8 in the python 
interpreter, please...!  a ×  b · c )

I doubt even people without looking around confusedly for a moment or 
three and searching for a definition buried in an import somewhere would 
know what s(x) does... Maybe D'Aprano likes it harder?

I mean --  D'Aprano -- a comment on a real world case?
Olifant says: """The biggest wart this would remove is the (ab)use of 
getitem to return new ranges and grids in NumPy (go use *mgrid* and *r_* 
in NumPy to see what I mean)."""

Stephenwlin ! (biggrin)
""" But if there's no difference, then why have ':' work specially for 
'[]' operations at all instead of requiring the user to build slice 
objects manually all the time? """

YES! YES! YES! Oh yeah!

  Duncan: (???)
""" Would this be a dict with a slice as key or value, or a set with a 
slice with a step?: {1:2:3} """

I think it would be a syntax error, just like it is now. It's a syntax 
error anywhere a slice WOULD precede a colon. The syntax is simple 
parser LALR logic, and is already in place.

But I doubt Stephen meant using it everywhere anyway, he did say """(almost?)"""
Stephen, I'm sure, knew ahead of time that:*  eg:
**not 1+::1 is 2::
_Besides_, Stephen's already mentioned parenthesis at least 4 times...


A programmer can always add () where an ambiguity exists, and the parser 
can generate syntax errors in all places where an ambiguity could arise.

if x:  # is never a slice,
if 1: 2:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list