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)?

Date 2013-02-25 01:10 +0000
From Andrew Robinson <andrew3@r3dsolutions.com>
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>
Newsgroups comp.lang.python
Message-ID <mailman.2495.1361783559.2939.python-list@python.org> (permalink)

Show all headers | 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