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

[Andrew Robinson]

On 02/14/2013 05:23 AM, Terry Reedy wrote:
> On 2/13/2013 2:00 PM, stephenwlin at gmail.com 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.

s=1:2:3
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 
a[1],a[2],a[5],a[11]

This is not a new idea: eg: 2002. (which is still status OPEN).
http://osdir.com/ml/python.patches/2002-06/msg00319.html

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...

http://technicaldiscovery.blogspot.com/2011/06/python-proposal-enhancements-i-wish-i.html
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: <http://mail.python.org/pipermail/python-list/attachments/20130225/70d0c00a/attachment.html>