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

Groups > comp.lang.python > #38826 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  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

Page 1 of 2  [1] 2  Next page →

#38826 — Suggested feature: slice syntax within tuples (or even more generally)?

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

See motivating discussion for this at:
    https://github.com/pydata/pandas/issues/2866

There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that:
    "e = ..." yields "e = Ellipsis"

Would there be any downside to changing the handling of ':' as well? It might even make the grammar simpler, in some ways, since indexers won't have to be treated specially.

Let me know if you have any thoughts.

Thanks!
Stephen

[toc] | [next] | [standalone]

#38842

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 believe the idea of slice literals has been rejected.

> See motivating discussion for this at:
>      https://github.com/pydata/pandas/issues/2866
>
> There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that:
>      "e = ..." yields "e = Ellipsis"

One dubious move does not justify another.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#38843

> 
> I believe the idea of slice literals has been rejected.
> 

That's too bad...do you have a link to prior discussion on this and what the reasoning was for rejection? There doesn't seem to be any particular downside and things would be more consistent with slice syntax allowed anywhere.

It would be helpful in other cases as well other than the one linked to, since there's good reason to be able to succinctly create and reuse the same indexer object multiple times without having to convert everything into slice() calls.

-Stephen

[toc] | [prev] | [next] | [standalone]

#38844

> 
> I believe the idea of slice literals has been rejected.
> 

That's too bad...do you have a link to prior discussion on this and what the reasoning was for rejection? There doesn't seem to be any particular downside and things would be more consistent with slice syntax allowed anywhere.

It would be helpful in other cases as well other than the one linked to, since there's good reason to be able to succinctly create and reuse the same indexer object multiple times without having to convert everything into slice() calls.

-Stephen

[toc] | [prev] | [next] | [standalone]

#38851

On Wed, 13 Feb 2013 21:54:43 -0800, stephenwlin wrote:


>> I believe the idea of slice literals has been rejected.
>> 
>> 
> That's too bad...do you have a link to prior discussion on this and what
> the reasoning was for rejection? There doesn't seem to be any particular
> downside and things would be more consistent with slice syntax allowed
> anywhere.

There's *always* downside to new syntax. The question is, does the 
benefit exceed the downside?

- new syntax requires more complexity in the parser;

- new tests for it;

- more documentation;

- increase in the number of things people have to learn before they can 
read and write Python code;

- takes the language further away from "executable pseudo-code" and 
closer to "line noise";

- somebody has to actually write the code, write the tests, write the 
documentation; and somebody else has to review it; for a chronically 
short-handed dev team where there are hundreds of bugs and feature 
requests in the queue, this is a significant cost.

Now, you might argue that these are all *low* cost, but they're not zero, 
and how do they stack up against the benefits?

What are the benefits of syntactic sugar for slice objects?

Personally, there's not much difference to my eye between:


S = slice
S(1, 20, 3)

versus

(1:20:3)

so I'm skeptical that the benefit is much greater than the cost, as low 
as that cost may be.


> It would be helpful in other cases as well other than the one linked to,
> since there's good reason to be able to succinctly create and reuse the
> same indexer object multiple times without having to convert everything
> into slice() calls.

I don't quite understand this argument. If you mean that you can do this:

s = (1:2)  # Like slice(1, 2).
print alist[s]
print blist[s]  # reuse the slice object
print clist[s]


you can replace the line s = (1:2) to a call to slice, and still reuse 
the slice object. So I don't understand what the syntactic sugar gains 
you.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#38855

> 
> 
> >> I believe the idea of slice literals has been rejected.
> 
> >> 
> 
> >> 
> 
> > That's too bad...do you have a link to prior discussion on this and what
> 
> > the reasoning was for rejection? There doesn't seem to be any particular
> 
> > downside and things would be more consistent with slice syntax allowed
> 
> > anywhere.
> 
> 
> 
> There's *always* downside to new syntax. The question is, does the 
> 
> benefit exceed the downside?
> 
> 
> 

Fair enough points w.r.t with the costs of implementation, etc. I just meant that, from my perspective, it seems like a simplification of the grammar rather than making it more complex, since it just makes ':' work the same way outside of [] as within it, instead of treating [] as a special case. I'm aware there could be some ambiguities with dictionary construction but it should be pretty easy to resolve with precedence rules.

As for making the language more complicated to learn: to be honest, the fact that ':' was treated specially in [] made things more confusing to me until I realized there was a special grammar specifically for that case (since this is not something I would expect coming from other languages). That there would be specific grammar for this case would make more sense if there was something about the __getitem__/__setitem__ protocol that inherently required it, but there isn't really: you're just passing an object to __getitem__ just like you can pass an object to any function, so why would you parse expressions differently in the former case versus the latter? Obviously, this depends on one's individual intuition though, so maybe I'm in the minority here in finding it weird.

> 
> 
> 
> What are the benefits of syntactic sugar for slice objects?
> 
> 
> 
> Personally, there's not much difference to my eye between:
> 
> 
> 
> 
> 
> S = slice
> 
> S(1, 20, 3)
> 
> 
> 
> versus
> 
> 
> 
> (1:20:3)
> 
> 
> 
> so I'm skeptical that the benefit is much greater than the cost, as low 
> 
> as that cost may be.

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? It obviously is a convenient and simpler syntax, and there doesn't seem to be any real reason for the artificial restriction that this happens inside '[]' (and in a shallow manner, so no nested slices or slices within tuples) only.

> 
> 
> 
> 
> 
> > It would be helpful in other cases as well other than the one linked to,
> 
> > since there's good reason to be able to succinctly create and reuse the
> 
> > same indexer object multiple times without having to convert everything
> 
> > into slice() calls.
> 
> 
> 
> I don't quite understand this argument. If you mean that you can do this:
> 
> 
> 
> s = (1:2)  # Like slice(1, 2).
> 
> print alist[s]
> 
> print blist[s]  # reuse the slice object
> 
> print clist[s]
> 
> 
> 
> 
> 
> you can replace the line s = (1:2) to a call to slice, and still reuse 
> 
> the slice object. So I don't understand what the syntactic sugar gains 
> 
> you.
> 
> 
> 

Yes, but you can't just directly use what you wrote within '[]' outside of it, and there doesn't seem to be any real technical reason for this except for historical evolution of the language. Obviously isn't not that hard to convert everything to call slice() manually but it can get verbose quickly for complex multidimensional slices cases (which are common in numpy, which is why Travis Oliphant wants this feature as well...)

You can do something hackish like make a dummy object that returns

class Indexer:
    def __getitem__(self, obj):
        return obj

I = Indexer()

s = I[1:2,..,3:4:-1,::-1]

but that seems that seems mostly to highlight the fact that this is an artificial problem to begin with...'[]' just translates to a function call anyway (more or less), so why treat it differently?

Thanks,

-Stephen

[toc] | [prev] | [next] | [standalone]

#38854

On Wed, 13 Feb 2013 21:54:43 -0800, stephenwlin wrote:

>> I believe the idea of slice literals has been rejected.
>> 
>> 
> That's too bad...do you have a link to prior discussion on this and what
> the reasoning was for rejection? 

http://osdir.com/ml/python.python-3000.devel/2006-05/msg00686.html
http://mail.python.org/pipermail/python-list/2001-August/094909.html

E.g.:

if x:
    pass


Is that intended as "if slice(x, None, None)" with a missing colon, or 
"if x" with colon supplied?

With the addition of one extra letter, you can use slice notation to 
return slice objects:

class SlicerAndDicer:
    def __getitem__(self, item):
        return item

s = SlicerAndDicer()


And some examples:

py> s[2::5]
slice(2, None, 5)
py> s[::-1]
slice(None, None, -1)
py> s[3, 4]
(3, 4)
py> s[3, 4:6]
(3, slice(4, 6, None))
py> s[7::, 9]
(slice(7, None, None), 9)


I feel all giddy inside...



By the way, Go-lang also has slices, but they're more like views into an 
array than Python's slice objects.

http://blog.golang.org/2011/01/go-slices-usage-and-internals.html


This is not germane to your question, I just found it interesting reading.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#38856

On Thursday, February 14, 2013 3:03:50 AM UTC-5, Steven D'Aprano wrote:
> On Wed, 13 Feb 2013 21:54:43 -0800, stephenwlin wrote:
> 
> 
> 
> >> I believe the idea of slice literals has been rejected.
> 
> >> 
> 
> >> 
> 
> > That's too bad...do you have a link to prior discussion on this and what
> 
> > the reasoning was for rejection? 
> 
> 
> 
> http://osdir.com/ml/python.python-3000.devel/2006-05/msg00686.html
> 
> http://mail.python.org/pipermail/python-list/2001-August/094909.html
> 
> 
> 
> E.g.:
> 
> 
> 
> if x:
> 
>     pass
> 
> 
> 
> 
> 
> Is that intended as "if slice(x, None, None)" with a missing colon, or 
> 
> "if x" with colon supplied?

I don't mean to argue with Guido, but unless I'm missing something, the former would be a syntax error and the latter would not be, so even if it might be ambiguous in isolation it wouldn't be in context. Isn't this something that could be resolved without requiring a mathematically more complex parser than Python already requires? (i.e. one that corresponds to a more complex minimal automaton).

Also, you could easily restrict that ':' cannot be in top-level expressions, so have to be enclosed with either () or [] (so the latter because just a specific case of a more general rule.)

> 
> 
> 
> With the addition of one extra letter, you can use slice notation to 
> 
> return slice objects:
> 
> 
> 
> class SlicerAndDicer:
> 
>     def __getitem__(self, item):
> 
>         return item
> 
> 
> 
> s = SlicerAndDicer()
> 
> 
> 
> 
> 
> And some examples:
> 
> 
> 
> py> s[2::5]
> 
> slice(2, None, 5)
> 
> py> s[::-1]
> 
> slice(None, None, -1)
> 
> py> s[3, 4]
> 
> (3, 4)
> 
> py> s[3, 4:6]
> 
> (3, slice(4, 6, None))
> 
> py> s[7::, 9]
> 
> (slice(7, None, None), 9)
> 

Hah, yes. I basically wrote that exact example in my reply to Steven at the same time you replied. numpy.s_ is similar (although I think it does some extra work for odd reasons).

Anyway this is an okay workaround, but it just seems to highlight the fact that the restriction of using ':' within [] is arbitrary to begin with, since all you're doing is wrapping a function call. Right now, everything which is parsed within f() is also parsed within f[], but the latter is parsing more things just by virtue of the fact that that it's a [] instead of ().

To be honest, this feels like more of an artifact of historical evolution than anything else. It just doesn't make much sense create a special syntax for parsing expressions into objects in one particular context but not others when there's nothing special about the underlying object protocol that requires it to be handled separately (and perhaps this was not always the case...I've not been with Python long enough to know the particulars of how this was implemented in the past...)

Anyway, thanks for the feedback!

- Stephen

[toc] | [prev] | [next] | [standalone]

#38857

> Hah, yes. I basically wrote that exact example in my reply to Steven at the same time you replied. numpy.s_ is similar (although I think it does some extra work for odd reasons).

Oops, this is silly in retrospect...sorry, wasn't looking at the From: line carefully enough and didn't realize I was responding to you again.

[toc] | [prev] | [next] | [standalone]

#38878

On Thu, Feb 14, 2013 at 1:03 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> E.g.:
>
> if x:
>     pass
>
>
> Is that intended as "if slice(x, None, None)" with a missing colon, or
> "if x" with colon supplied?

That's not ambiguous, because the former is simply invalid syntax.
However, consider the following.

if 1: 2:

That could be either a one-line if statement where the condition is 1
and the body is slice(2, None), or it could be the beginning of a
multi-line if block where the condition is slice(1, 2).  If the parser
sees that, should it expect the next line to be indented or not?  If
it relies on indentation to determine this, then it loses some ability
to warn the user of incorrect indentation.

Then we have dictionary literals:

{1:2:3}

Should that be read as dict([(slice(1, 2), 3)]) or dict([(1, slice(2,
3))])?  Or even set([slice(1, 2, 3)])?

[toc] | [prev] | [next] | [standalone]

#38888

On Thursday, February 14, 2013 1:58:06 PM UTC-5, Ian wrote:
> 
> That's not ambiguous, because the former is simply invalid syntax.
> 
> However, consider the following.
> 
> 
> 
> if 1: 2:
> 
> 
> 
> That could be either a one-line if statement where the condition is 1
> 
> and the body is slice(2, None), or it could be the beginning of a
> 
> multi-line if block where the condition is slice(1, 2).  If the parser
> 
> sees that, should it expect the next line to be indented or not?  If
> 
> it relies on indentation to determine this, then it loses some ability
> 
> to warn the user of incorrect indentation.
> 
> 
> 
> Then we have dictionary literals:
> 
> 
> 
> {1:2:3}
> 
> 
> 
> Should that be read as dict([(slice(1, 2), 3)]) or dict([(1, slice(2,
> 
> 3))])?  Or even set([slice(1, 2, 3)])?
>

Restricting this to within the top level of ()-enclosed expressions would be sufficient to eliminate all ambiguities, though, right? Basically all that needs to change is for expressions within '()' to be parsed identically as are currently parsed in '[]'.

-Stephen

[toc] | [prev] | [next] | [standalone]

#38889

On Thursday, February 14, 2013 1:58:06 PM UTC-5, Ian wrote:
> 
> That's not ambiguous, because the former is simply invalid syntax.
> 
> However, consider the following.
> 
> 
> 
> if 1: 2:
> 
> 
> 
> That could be either a one-line if statement where the condition is 1
> 
> and the body is slice(2, None), or it could be the beginning of a
> 
> multi-line if block where the condition is slice(1, 2).  If the parser
> 
> sees that, should it expect the next line to be indented or not?  If
> 
> it relies on indentation to determine this, then it loses some ability
> 
> to warn the user of incorrect indentation.
> 
> 
> 
> Then we have dictionary literals:
> 
> 
> 
> {1:2:3}
> 
> 
> 
> Should that be read as dict([(slice(1, 2), 3)]) or dict([(1, slice(2,
> 
> 3))])?  Or even set([slice(1, 2, 3)])?
>

Restricting this to within the top level of ()-enclosed expressions would be sufficient to eliminate all ambiguities, though, right? Basically all that needs to change is for expressions within '()' to be parsed identically as are currently parsed in '[]'.

-Stephen

[toc] | [prev] | [next] | [standalone]

#38900

On Thursday, February 14, 2013 4:01:39 PM UTC-6, steph...@gmail.com wrote:
> On Thursday, February 14, 2013 1:58:06 PM UTC-5, Ian wrote:
> 
> [snip: quote noise!]
> 

Dude! Please trim this quote noise from your posts. I know Google's quoting mechanism is buggy, but dammit man YOU'RE A PROGRAMER! There is no excuse for not trimming excessive newlines.

============================================================
 As to your slicing request.
============================================================

Anybody who knows me KNOWS that i love consistency! So i'm all for applying a slicing syntax consistently, however, i don't think your approach is the correct approach. 

To get you going in the correct direction: Ruby uses the  "s..e" and "s...e" (where "s" represents the start of the range and "e" represents the end of a range) as syntactic sugar for Range.new(s, e). Two dots create an /inclusive/ range and three dots create an /exclusive/ range. Anyway, enough tutorials, read the doc:

  http://www.ruby-doc.org/core-1.9.3/Range.html

Now, i am not suggesting that python should adopt the /exact/ syntax of Ruby, however, i /am/ suggesting that Ruby is more consistent with the range object than Python.

In Ruby:

...you can slice arrays with the range:
 
rb> a = [1,2,3,4,5]
rb> a[0..-1]
[1,2,3,4,5]
rb> a[0...-1]
[1,2,3,4]

...you can create a range of integers :

rb> r = 1..10 
rb> r.to_a()
[1,2,3,4,5,6,7,8,9]

...you can create a range of chars:

rb> r = "a".."d"
rb> r.to_a()
["a", "b", "c", "d"]

...you can use range in a loop:

rb> for x in 0...5;puts "#{x}th iteration";end
0th iteration
1th iteration
2th iteration
3th iteration
4th iteration

...but most importantly, you can do all these things in a consistent manner using a consistent syntax!

Python however has the stupid slice function and then sequence indexing, and no consistency between the two! Plus, the for loop uses the range function to create "lazy iterators" instead of employing a consistent "range" syntax.

Consistent syntax and consistent application are the biggest issues with Python ranges as they exist today. That's the starting point.

[toc] | [prev] | [next] | [standalone]

#38901

On Thursday, February 14, 2013 4:01:39 PM UTC-6, steph...@gmail.com wrote:
> On Thursday, February 14, 2013 1:58:06 PM UTC-5, Ian wrote:
> 
> [snip: quote noise!]
> 

Dude! Please trim this quote noise from your posts. I know Google's quoting mechanism is buggy, but dammit man YOU'RE A PROGRAMER! There is no excuse for not trimming excessive newlines.

============================================================
 As to your slicing request.
============================================================

Anybody who knows me KNOWS that i love consistency! So i'm all for applying a slicing syntax consistently, however, i don't think your approach is the correct approach. 

To get you going in the correct direction: Ruby uses the  "s..e" and "s...e" (where "s" represents the start of the range and "e" represents the end of a range) as syntactic sugar for Range.new(s, e). Two dots create an /inclusive/ range and three dots create an /exclusive/ range. Anyway, enough tutorials, read the doc:

  http://www.ruby-doc.org/core-1.9.3/Range.html

Now, i am not suggesting that python should adopt the /exact/ syntax of Ruby, however, i /am/ suggesting that Ruby is more consistent with the range object than Python.

In Ruby:

...you can slice arrays with the range:
 
rb> a = [1,2,3,4,5]
rb> a[0..-1]
[1,2,3,4,5]
rb> a[0...-1]
[1,2,3,4]

...you can create a range of integers :

rb> r = 1..10 
rb> r.to_a()
[1,2,3,4,5,6,7,8,9]

...you can create a range of chars:

rb> r = "a".."d"
rb> r.to_a()
["a", "b", "c", "d"]

...you can use range in a loop:

rb> for x in 0...5;puts "#{x}th iteration";end
0th iteration
1th iteration
2th iteration
3th iteration
4th iteration

...but most importantly, you can do all these things in a consistent manner using a consistent syntax!

Python however has the stupid slice function and then sequence indexing, and no consistency between the two! Plus, the for loop uses the range function to create "lazy iterators" instead of employing a consistent "range" syntax.

Consistent syntax and consistent application are the biggest issues with Python ranges as they exist today. That's the starting point.

[toc] | [prev] | [next] | [standalone]

#38846

Apparently Travis Oliphant of numpy would like this as well...

http://technicaldiscovery.blogspot.com/2011/06/python-proposal-enhancements-i-wish-i.html

On Wednesday, February 13, 2013 2:00:15 PM UTC-5, steph...@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)"
> 
> 
> 
> See motivating discussion for this at:
> 
>     https://github.com/pydata/pandas/issues/2866
> 
> 
> 
> There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that:
> 
>     "e = ..." yields "e = Ellipsis"
> 
> 
> 
> Would there be any downside to changing the handling of ':' as well? It might even make the grammar simpler, in some ways, since indexers won't have to be treated specially.
> 
> 
> 
> Let me know if you have any thoughts.
> 
> 
> 
> Thanks!
> 
> Stephen

[toc] | [prev] | [next] | [standalone]

#38863

stephenwlin@gmail.com wrote:

> 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? 
> 
Would this be a dict with a slice as key or value, or a set with a slice 
with a step?:

    {1:2:3}

You can't just allow ':' to generate slice objects everwhere without 
introducing ambiguity, so your proposal would have to be to allow slice 
objects in wider but still restricted contexts.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#38867

> 
> You can't just allow ':' to generate slice objects everwhere without 
> 
> introducing ambiguity, so your proposal would have to be to allow slice 
> 
> objects in wider but still restricted contexts.

Yeah, I mentioned that in a follow-up. I'm pretty sure of just allowing it within [] and () would work, though, and still be a pretty consistent/simple grammar.

This would also remove Steven's (i.e. Guido's) objection that about

if x:

This would still preserves the main benefit of allowing you to succinctly create slices in any context you need an expression in, because you can always add () around any expression.

-Stephen

[toc] | [prev] | [next] | [standalone]

#39882

[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:

[toc] | [prev] | [next] | [standalone]

#39884

On Sun, Feb 24, 2013 at 6:10 PM, Andrew Robinson
<andrew3@r3dsolutions.com> wrote:
> 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) :

Eww, no.  I can appreciate the appeal of this syntax, but the problem
is that ranges and slices are only superficially similar.  For one,
ranges require a stop value; slices do not.  What should Python do
with this:

for i in (:):

Intuitively, it should result in an infinite loop starting at 0.  But
ranges require a stop value for a very good reason -- it should not be
this easy to accidentally create an infinite for loop.  So I would
advocate that this should raise an error instead.  If the user really
wants an unlimited counting loop, let them continue to be explicit
about it by using itertools.count.  On the other hand, this would mean
that the semantics of (:) would be different depending on whether the
slice is used as a slice or a range.

The next problem you run into is that the semantics of negative
numbers are completely different between slices and ranges.  Consider
this code:

s = (-5:6)
for i in s:
    print(i)
for i in range(6)[s]:
    print(i)

Intuitively, both loops should print the same thing.  After all, one
is using the slice s as a range, and the other is using the very same
slice s as a slice of a sequence where the indices and values are the
same.  This expectation fails, however.  The first loop prints the
integers from -5 to 5 inclusive, and the second loop only prints the
integers from 1 to 5 inclusive.

For these reasons, I disagree that allowing slices to be implicitly
converted to ranges or vice versa is a good idea.

> This is not a new idea: eg: 2002. (which is still status OPEN).
> http://osdir.com/ml/python.patches/2002-06/msg00319.html

It's not still open.  What you've linked above is an archived mailing
list message concerning the patch.  I've linked the actual tracker
issue that the patch was attached below; it was rejected by Guido in
2002.
http://bugs.python.org/issue575515

[toc] | [prev] | [next] | [standalone]

#39886

On 2/24/2013 8:10 PM, Andrew Robinson wrote:

> This is not a new idea: eg: 2002. (which is still status OPEN).
> http://osdir.com/ml/python.patches/2002-06/msg00319.html
http://bugs.python.org/issue575515
closed as rejected 2 weeks after being opened.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web