Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #39882

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

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 <andrew3@r3dsolutions.com>
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 <andrew3@r3dsolutions.com>
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> <kfhsc2$ubq$1@ger.gmane.org>
In-Reply-To <kfhsc2$ubq$1@ger.gmane.org>
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 <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.2495.1361783559.2939.python-list@python.org> (permalink)
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

Show key headers only | View raw


[Multipart message — attachments visible in raw view] - view raw

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:

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-13 11:00 -0800
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Terry Reedy <tjreedy@udel.edu> - 2013-02-14 00:23 -0500
    Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-13 21:54 -0800
    Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-13 21:54 -0800
      Re: Suggested feature: slice syntax within tuples (or even more generally)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-14 07:32 +0000
        Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-14 00:36 -0800
      Re: Suggested feature: slice syntax within tuples (or even more generally)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-14 08:03 +0000
        Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-14 01:08 -0800
          Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-14 01:26 -0800
        Re: Suggested feature: slice syntax within tuples (or even more generally)? Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-14 11:58 -0700
          Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-14 14:01 -0800
          Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-14 14:01 -0800
            Re: Suggested feature: slice syntax within tuples (or even more generally)? Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-14 17:46 -0800
            Re: Suggested feature: slice syntax within tuples (or even more generally)? Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-14 17:46 -0800
  Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-13 22:06 -0800
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Duncan Booth <duncan.booth@invalid.invalid> - 2013-02-14 12:25 +0000
    Re: Suggested feature: slice syntax within tuples (or even more generally)? stephenwlin@gmail.com - 2013-02-14 07:56 -0800
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Andrew Robinson <andrew3@r3dsolutions.com> - 2013-02-25 01:10 +0000
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-25 03:28 -0700
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Terry Reedy <tjreedy@udel.edu> - 2013-02-25 06:23 -0500
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-25 09:54 -0700
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Andrew Robinson <andrew3@r3dsolutions.com> - 2013-02-25 09:47 +0000
  Re: Suggested feature: slice syntax within tuples (or even more generally)? Nobody <nobody@nowhere.com> - 2013-02-26 07:38 +0000

csiph-web