<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/14/2013 05:23 AM, Terry Reedy
wrote:<br>
</div>
<blockquote cite="mid:kfhsc2$ubq$1@ger.gmane.org" type="cite">On
2/13/2013 2:00 PM, <a class="moz-txt-link-abbreviated"
href="mailto:stephenwlin@gmail.com">stephenwlin@gmail.com</a>
wrote: <br>
<blockquote type="cite">Hello, <br>
<br>
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? <br>
<br>
Right now in Py2.7, Py3.3: <br>
"obj[:,2]" yields "obj[slice(None),2]" <br>
but <br>
"obj[(:,1),2]" is an error, instead of "obj[(slice(None),
1), 2]" <br>
<br>
Also, more generally, you could imagine this working in
(almost?) any expression without ambiguity: <br>
"a = (1:2)" could yield "a = slice(1,2)" <br>
</blockquote>
<br>
</blockquote>
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.<br>
<br>
s=1:2:3<br>
for i in s:<br>
for i in (1:2:3) :<br>
and I really don't even mind, for i in s[a]:<br>
or even a[1,2,5,11] where the indicies are equivalent to *sequence*
other than xrange.<br>
Python evaluates right to left; this is semantically an iterator
giving a[1],a[2],a[5],a[11]<br>
<br>
This is not a new idea: eg: 2002. (which is still status OPEN).<br>
<a class="moz-txt-link-freetext"
href="http://osdir.com/ml/python.patches/2002-06/msg00319.html">http://osdir.com/ml/python.patches/2002-06/msg00319.html</a><br>
<br>
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.<br>
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...<br>
<br>
On Travis Oliphant: I agree...<br>
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...<br>
<br>
<a class="moz-txt-link-freetext"
href="http://technicaldiscovery.blogspot.com/2011/06/python-proposal-enhancements-i-wish-i.html">http://technicaldiscovery.blogspot.com/2011/06/python-proposal-enhancements-i-wish-i.html</a><br>
PEP 225's... desire for readability is important to me too ... even
if a fork happens.<br>
( An aside: I hate line noise, and fights, so UTF8 in the python
interpreter, please...! a × b · c )<br>
<br>
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?<br>
<br>
I mean -- D'Aprano -- a comment on a real world case?<br>
Olifant says: """The biggest wart this would remove is the (ab)use
of getitem to return new ranges and grids in NumPy (go use <b><span
style="font-family: "Courier New",Courier,monospace;">mgrid</span></b>
and <b><span style="font-family: "Courier
New",Courier,monospace;">r_</span></b> in NumPy to see what
I mean)."""<br>
<br>
#=========<br>
Stephenwlin ! (biggrin) <br>
""" 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? """ <br>
<br>
YES! YES! YES! Oh yeah!<br>
<br>
#=========<br>
Duncan: (???)<br>
""" Would this be a dict with a slice as key or value, or a set with
a slice with a step?: {1:2:3} """<br>
<br>
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. <br>
<pre wrap=""><big>But I doubt Stephen meant using it everywhere anyway, he did say """(almost?)"""
Stephen, I'm sure, knew ahead of time that:</big><b> eg:
</b><b>not 1+::1 is 2::
</b><big>
<u>Besides</u>, Stephen's already mentioned parenthesis at least 4 times...</big>
</pre>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
A programmer can always add () where an ambiguity exists, and the
parser can generate syntax errors in all places where an ambiguity
could arise.<br>
<br>
if x: # is never a slice,<br>
if 1: 2: <br>
<br>
</body>
</html>