Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'syntax': 0.03; 'value,': 0.03; '"""': 0.05; 'modify': 0.05; 'parser': 0.07; 'python': 0.09; 'ambiguity': 0.09; 'core,': 0.09; 'dict': 0.09; 'difference,': 0.09; 'exists,': 0.09; 'fork': 0.09; 'happens.': 0.09; 'interpreter,': 0.09; 'pep': 0.09; 'sure,': 0.09; 'terry': 0.09; 'utf8': 0.09; 'language,': 0.11; 'programmer': 0.11; "':'": 0.16; '1),': 0.16; 'colon.': 0.16; 'evaluates': 0.16; 'feasible': 0.16; 'idea:': 0.16; 'iterator': 0.16; 'left;': 0.16; 'numpy': 0.16; 'precede': 0.16; 'readable': 0.16; 'reedy': 0.16; 'semantically': 0.16; 'slice,': 0.16; 'subject:)?': 0.16; 'top-level': 0.16; 'travis': 0.16; 'url:patches': 0.16; 'wrote:': 0.17; 'community,': 0.17; 'implementing': 0.17; 'yield': 0.17; 'equivalent': 0.20; 'import': 0.21; 'meant': 0.21; 'simpler': 0.22; 'stephen': 0.22; 'tuples': 0.22; 'errors': 0.23; 'specially': 0.23; "i've": 0.23; 'somewhere': 0.24; 'script': 0.24; 'least': 0.25; 'header:In- Reply-To:1': 0.25; 'header:User-Agent:1': 0.26; '(which': 0.26; 'skip:" 20': 0.26; 'am,': 0.27; "d'aprano": 0.29; 'idea,': 0.29; 'implicitly': 0.29; 'mind,': 0.29; 'url:06': 0.29; 'yields': 0.29; 'definition': 0.29; 'no,': 0.29; 'objects': 0.29; "i'm": 0.29; 'maybe': 0.29; 'communities': 0.30; 'error': 0.30; 'code': 0.31; 'point': 0.31; '(and': 0.32; 'url:python': 0.32; 'could': 0.32; 'anywhere': 0.33; 'doubt': 0.33; 'legacy': 0.33; 'mixed': 0.33; 'raising': 0.33; 'to:addr:python-list': 0.33; 'operations': 0.33; 'ahead': 0.35; 'requiring': 0.35; 'pm,': 0.35; 'add': 0.36; 'really': 0.36; 'but': 0.36; 'loaded': 0.36; 'scientific': 0.36; 'too': 0.36; 'subject: (': 0.36; 'level': 0.37; 'why': 0.37; 'moment': 0.37; 'quite': 0.37; 'rather': 0.37; 'subject:: ': 0.38; 'comment': 0.38; 'easier': 0.38; 'mean': 0.38; 'some': 0.38; 'instead': 0.39; 'to:addr:python.org': 0.39; 'build': 0.39; 'hello,': 0.39; 'where': 0.40; 'skip:" 10': 0.40; 'think': 0.40; 'range': 0.60; 'remove': 0.61; 'high': 0.61; 'real': 0.61; 'places': 0.61; 'future.': 0.62; 'received:phx3.secureserver.net': 0.62; 'received:prod.phx3.secureserver.net': 0.62; 'mentioned': 0.63; 'world': 0.63; 'email addr:gmail.com': 0.63; 'more': 0.63; 'url:blogspot': 0.64; 'making': 0.64; 'header:Reply-To:1': 0.68; 'biggest': 0.71; 'ranges': 0.71; 'reply-to:no real name:2**0': 0.72; 'url:2011': 0.72; 'attractive': 0.78; 'arise.': 0.84; 'case?': 0.84; 'noise,': 0.84; 'received:173.201.192.110': 0.84; 'received:p3plsmtpa06-09.prod.phx3.secureserver.net': 0.84; 'url:ml': 0.84; 'received:173.201': 0.91; 'received:173.201.192': 0.91; 'besides,': 0.93; 'hate': 0.93; 'yes!': 0.93; 'imagine': 0.96 Date: Mon, 25 Feb 2013 01:10:26 +0000 From: Andrew Robinson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120909 Thunderbird/15.0.1 MIME-Version: 1.0 To: python-list@python.org Subject: Re: Suggested feature: slice syntax within tuples (or even more generally)? References: <2e07acfb-4f48-4a27-9b06-3d8103325c0f@googlegroups.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020308060603070708030507" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: andrew3@r3dsolutions.com List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 296 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1361783559 news.xs4all.nl 6915 [2001:888:2000:d::a6]:51293 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:39882 This is a multi-part message in MIME format. --------------020308060603070708030507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 02/14/2013 05:23 AM, Terry Reedy wrote: > On 2/13/2013 2:00 PM, stephenwlin@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: --------------020308060603070708030507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/14/2013 05:23 AM, Terry Reedy wrote:
On 2/13/2013 2:00 PM, stephenwlin@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:

--------------020308060603070708030507--