Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #39882
| 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) |
[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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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