Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Suggested feature: slice syntax within tuples (or even more generally)?

Reply
Thread Tools

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

 
 
Ian Kelly
Guest
Posts: n/a
 
      02-14-2013
On Thu, Feb 14, 2013 at 1:03 AM, Steven D'Aprano
<(E-Mail Removed)> 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)])?
 
Reply With Quote
 
 
 
 
stephenwlin@gmail.com
Guest
Posts: n/a
 
      02-14-2013
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

 
Reply With Quote
 
 
 
 
stephenwlin@gmail.com
Guest
Posts: n/a
 
      02-14-2013
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

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-15-2013
On Thursday, February 14, 2013 4:01:39 PM UTC-6, (E-Mail Removed) 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 quotingmechanism 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 applyinga slicing syntax consistently, however, i don't think your approach is thecorrect 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 mannerusing 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.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-15-2013
On Thursday, February 14, 2013 4:01:39 PM UTC-6, (E-Mail Removed) 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 quotingmechanism 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 applyinga slicing syntax consistently, however, i don't think your approach is thecorrect 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 mannerusing 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.
 
Reply With Quote
 
Andrew Robinson
Guest
Posts: n/a
 
      02-25-2013
On 02/25/2013 04:54 PM, Ian Kelly wrote:
> On Mon, Feb 25, 2013 at 12:41 AM, Andrew Robinson
> <(E-Mail Removed)> wrote:
>>> 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.

>> ...
>> and, besides, the same is true with other constructions of loops....
>>
>> while a: # Damn easy, if a is accidentally true!

> Notice I specifically said an "infinite *for* loop".

OK, so tit for tat.

Notice I already showed an effective *accidental* "infinite" for loop
because I did notice you spoke about a *for* loop.

And, obviously, in the case of the while loop I showed -- it was not
meant to be True forever.
It's a variable, which is subject to change.

I really do respect your opinion; but it's one of about 5 people that
dominate this list, albeit the same spend a lot of time helping others;
Stephen is someone new to me, and I want to encourage his probing of the
issue more than I want to advance my view.

P.S.
I apologize about the e-mail clock, it seems I am sending my local time
again -- and it's different from your timezone; I *wish* the python list
computer would politely adjust it when *accidents* happen, or my OS's
distribution would fix their bug -- but cest la vie. I limp along with
the status quo for now.




 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      02-25-2013
On Sun, Feb 24, 2013 at 6:10 PM, Andrew Robinson
<(E-Mail Removed)> 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/2.../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
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      02-25-2013
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/2.../msg00319.html

http://bugs.python.org/issue575515
closed as rejected 2 weeks after being opened.


--
Terry Jan Reedy

 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      02-25-2013
On Mon, Feb 25, 2013 at 12:41 AM, Andrew Robinson
<(E-Mail Removed)> wrote:
>> 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.

>
> ...
> and, besides, the same is true with other constructions of loops....
>
> while a: # Damn easy, if a is accidentally true!


Notice I specifically said an "infinite *for* loop". While loops are
meant to be indeterminate in the number of iterations they will take
going into the loop; for loops are not.

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

>
> I don't find this difference to be necessary, nor objectionable.
>
> It is less inconsistent, in my view, to allow that
> ([ 1,2,3,4,5 ])[-1:2] produce [5,1,2] than an empty list;
> and ([ 1,2,3,4,5])[2:-1] does produce an empty list.
>
> I have been looking for actual programs that this would break for over two
> months now, and I haven't been finding any. I am willing to run any
> mainstream application you can find on test-patched python!


Yes, I recollect now that we have already had this discussion.
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      02-26-2013
On Wed, 13 Feb 2013 11:00:15 -0800, stephenwlin 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?


If you need to be able to easily construct indexing objects, create a
helper like:

> class Slicer(object):

= def __getitem__(self, s):
= return s
=
> s_ = Slicer()
> s_[1,2,3]

(1, 2, 3)
> s_[:]

slice(None, None, None)
> s_[1:2:3,4:5:6]

(slice(1, 2, 3), slice(4, 5, 6))
> s_[...]

Ellipsis

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Suggested feature: slice syntax within tuples (or even moregenerally)? Andrew Robinson Python 0 02-25-2013 08:45 AM
Re: Suggested feature: slice syntax within tuples (or even moregenerally)? Andrew Robinson Python 0 02-25-2013 01:33 AM
Dictionaries with tuples or tuples of tuples Jon Reyes Python 18 02-19-2013 03:56 AM
tuples within tuples korovev76@gmail.com Python 12 10-27-2007 08:16 PM
Different tuples to one container? (One type of a pointer to point to different kinds of tuples?) fff_afafaf@yahoo.com C++ 5 10-05-2006 11:17 PM



Advertisments