On 02/14/2013 05:23 AM, Terry Reedy wrote:
On 2/13/2013 2:00 PM, stephenw...@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:
--
http://mail.python.org/mailman/listinfo/python-list
