On Sun, Feb 1, 2015 at 10:51 PM, Greg Ewing wrote:

Eugene Toder wrote:

...

It may be too late for this, but I like it. We can also elide extra parentheses inside calls, like with generator expressions: sum(4:10:2)

Also, using list comprehension to generator expression analogy, we can have [4:10:2]

But putting those two analogies together, (4:10:2) on its own should be a generator expression rather than a range object.

Yes, I also considered that approach, but decided against proposing it for that reason.

On 2015-02-01, at 18:27 , Steven D'Aprano wrote:

It isn't meaningful to define a range with an unspecified stop

Wouldn't that just be an infinite sequence, equivalent to `itertools.count`? That's how it works in Haskell[0] and Clojure[1]. [0] using the range notation, or Enum's methods [1] https://clojuredocs.org/clojure.core/range

On Sun, Feb 01, 2015 at 10:18:33PM +0100, Todd wrote:

On Feb 1, 2015 6:27 PM, "Steven D'Aprano" wrote:

...

In other words, the similarity between slices and ranges is not as close as you think.

Fair enough. But it doesn't really affect my proposal. It would just be that this syntax only allows a subset of what you can do with slices.

It undercuts the justification for the proposal. Greg has also shown that even with purely integer values, slices and ranges behave differently. Slice objects are not a special case of ranges, and ranges are not a special case of slice objects. They behave differently, have different restrictions on their parameters, and different purposes. As far as I can see, virtually the only similarity is the names of the three parameters: start, stop, step. You might object that there is an important similarity that I've missed: slices (well, some slices) provide the same integer indexes as range does. That is, for at least *some* combinations of integers a, b and c, we have this invariant: seq[a:b:c] == [seq[i] for i in range(a, b, c)] But that's not a property of the slice object, that's a property of the sequence! Slice object merely record the start, stop, step, which can be arbitrary values in arbitrary order, and the sequence decides how to interpret it. The docs carefully don't describe the meaning of a slice object except as a bundle of start, stop, step attributes: https://docs.python.org/3/library/functions.html#slice That's because slice objects don't have any meaning except that which the sequence chooses to give it. That is not true for range objects. (By the way, the docs are wrong when they say slice objects have no other explicit functionality: they also have an indices method.) The above invariant is the conventional meaning, of course, and I'm not suggesting that there are a lot of classes that ignore that conventional meaning and do something else. But slice objects exist to be a simple bundle of three attributes with arbitrary values, and ranges exist to be a linear iterable of integers. The fact that sometimes they appear to kind of almost overlap in meaning is incidental. -- Steven

But it is meaningful to have a range with an unspecified stop. That's itertools.count. On Sunday, February 1, 2015 at 12:27:53 PM UTC-5, Steven D'Aprano wrote:

On Sun, Feb 01, 2015 at 04:13:32PM +0100, Todd wrote:

...

Although slices and ranges are used for different things and implemented differently, conceptually they are similar: they define an integer sequence with a start, stop, and step size.

I'm afraid that you are mistaken. Slices do not necessarily define integer sequences. They are completely arbitrary, and it is up to the object being sliced to interpret what is or isn't valid and what the slice means.

py> class K(object): ... def __getitem__(self, i): ... print(i) ... py> K()["abc":(2,3,4):{}] slice('abc', (2, 3, 4), {})

In addition, the "stop" argument to a slice may be unspecified until it it applied to a specific sequence, while range always requires stop to be defined.

py> s = slice(1, None, 2) py> "abcde"[s] 'bd' py> "abcdefghi"[s] 'bdfh'

It isn't meaningful to define a range with an unspecified stop, but it is meaningful to do so for slices.

In other words, the similarity between slices and ranges is not as close as you think.

-- Steven _______________________________________________ Python-ideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Feb 2, 2015 at 9:29 AM, Neil Girdhar wrote:

This proposal is definitely *possible*, but is the only argument in its favor saving 5 characters? You already have the shorthand exactly when you most need it (indexing).

As I indicated in an earlier response, there is some performance value to replacing the range function call with this (or other) syntactic sugar. While exceedingly rare, there is nothing to prevent a programmer from redefining the range builtin function or inserting a different version of range() in the local or global scopes: def my_range(*args): # completely ignore args, returning something weird... return [1, "a", None, 2] import __builtin__ __builtin__.range = my_range If you have a for loop which uses range(): for i in range(27): do something interesting with i optimizers like PyPy which aim to be precisely compatible with CPython semantics must look up "range" every time it occurs and decide if it's the real builtin range function, in which case it can emit/execute machine code which is something like the C for loop: for (i=start; i

On Mon, Feb 2, 2015 at 10:00 AM, Skip Montanaro wrote:

As I indicated in an earlier response, there is some performance value to replacing the range function call with this (or other) syntactic sugar.

It's my impression that adding stuff like this primarily for performance is nothing on the list ;-) But you could get the same effect by making range a keyword -- how often does anyone re-define it? And if you allow variables: range(i,j,k) or (i:j:k) Then any optimizer needs to to run-time type checking, or type inference, or what have you anyway, so checking if the name range is the range object seems like a small issue. FWIW, Cython does turn range calls into simple C loops: for i in range(10): becomes: for (__pyx_t_1 = 0; __pyx_t_1 < 10; __pyx_t_1+=1) { ... } In that case, the cython "language" doesn't allow re-defining of "range" And it will do this if either literals or variables that have been type-def'd as integer types are passed in as arguments. What difference this really makes to performance I have no idea -- you'd have to have something pretty trivial in that loop to notice it. -Chris

While exceedingly rare, there is nothing to prevent a programmer from redefining the range builtin function or inserting a different version of range() in the local or global scopes:

def my_range(*args): # completely ignore args, returning something weird... return [1, "a", None, 2]

import __builtin__ __builtin__.range = my_range

If you have a for loop which uses range():

for i in range(27): do something interesting with i

optimizers like PyPy which aim to be precisely compatible with CPython semantics must look up "range" every time it occurs and decide if it's the real builtin range function, in which case it can emit/execute machine code which is something like the C for loop:

for (i=start; i

or not, in which case it has to call whatever range is, then respond with its list of (arbtrary) Python objects.

Syntactic sugar would lock down the standard behavior.

Skip _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

Skip Montanaro wrote:

optimizers like PyPy which aim to be precisely compatible with CPython semantics must look up "range" every time it occurs and decide if it's the real builtin range function, in which case it can emit/execute machine code which is something like the C for loop:

for (i=start; i

I'd rather have a more flexible way of ierating over integer ranges that's not biased towards closed-start open-end intervals. While that's convenient for indexing sequences, if that's all you want to do you're better off iterating over the sequence directly, maybe using enumerate and/or zip. If you really need to iterate over ints, you probably need them for some other purpose, in which case you're likely to want any combination of open/closed start/end. For Pyrex I came up with a syntax that allows specifying any combination equally easily and clearly: for 0 <= i < 10: # closed start, open end for 0 <= i <= 10: # both ends closed for 0 < i < 10: # both ends open for 10 >= i >= 0: # both ends closed, going backwards etc. I think something like this would be a much better use of new syntax than just syntactic sugar for something that's not used very often. -- Greg

Please go read PEP 204, as Nick suggested. It would be nice if there was more Kongo as to why it was rejected, but it was, indeed, rejected. I also recall a lot of drawn out threads about more compact syntax for a for loop over integers, such as making the integer object iterable: for I in 10: pass Which were also all rejected. Unless someone comes up with a compelling argument that something has changed, it seems this conversation has been had already. -Chris On Feb 2, 2015, at 7:02 AM, Neil Girdhar wrote: But it is meaningful to have a range with an unspecified stop. That's itertools.count. On Sunday, February 1, 2015 at 12:27:53 PM UTC-5, Steven D'Aprano wrote:

On Sun, Feb 01, 2015 at 04:13:32PM +0100, Todd wrote:

...

Although slices and ranges are used for different things and implemented differently, conceptually they are similar: they define an integer sequence with a start, stop, and step size.

I'm afraid that you are mistaken. Slices do not necessarily define integer sequences. They are completely arbitrary, and it is up to the object being sliced to interpret what is or isn't valid and what the slice means.

py> class K(object): ... def __getitem__(self, i): ... print(i) ... py> K()["abc":(2,3,4):{}] slice('abc', (2, 3, 4), {})

In addition, the "stop" argument to a slice may be unspecified until it it applied to a specific sequence, while range always requires stop to be defined.

py> s = slice(1, None, 2) py> "abcde"[s] 'bd' py> "abcdefghi"[s] 'bdfh'

It isn't meaningful to define a range with an unspecified stop, but it is meaningful to do so for slices.

In other words, the similarity between slices and ranges is not as close as you think.

-- Steven _______________________________________________ Python-ideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Feb 2, 2015 at 5:11 PM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:

Please go read PEP 204, as Nick suggested. It would be nice if there was more Kongo as to why it was rejected, but it was, indeed, rejected.

I also recall a lot of drawn out threads about more compact syntax for a for loop over integers, such as making the integer object iterable:

for I in 10: pass

Which were also all rejected.

Unless someone comes up with a compelling argument that something has changed, it seems this conversation has been had already.

My syntax is not identical to the syntax proposed there, and in was chosen, in part, to avoid some of the issues that were responsible for its rejection. The reasons given for rejection were "open issues" and "some confusion between ranges and slice syntax". For the latter, part of my reason for using parentheses instead of brackets is to avoid potential confusion. So without knowing what specific confusion was being referred to I can't say whether this complaint is relevant or not. For the open issues, all of the issues are either no longer relevant in python 3 or are not applicable to my proposed syntax. The first is fixed by the python 3 range type, the fourth is fixed by the elimination of the long type in python 3, and the second, third, and fifth are not relevant to my proposed syntax (in fact I chose parentheses instead of brackets partly to avoid ambiguities and complications like these).

On Mon, 2 Feb 2015 07:38:52 +1100 Chris Angelico wrote:

On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver wrote:

...

Iterating over a slice object would work like you were lazily taking that slice from itertools.count() - i.e. iter(a:b:c) would be equivalent to islice(count(), a, b, c). This would also mean that (3:) would have a logical meaning without having to modify range objects to support an optional upper bound. I don't see any logical way to iterate over a slice defined with negative numbers (e.g. (-4:)), so presumably iter(-4:) would raise an exception.

If you're going to start defining things in terms of itertools.count(), I'd prefer to first permit a range object to have an infinite upper bound, and then define everything in terms of a sliced range - range objects already support clean slicing.

Is there any particular reason for range objects to disallow infinite bounds, or is it just that nobody's needed it?

If the platform's Py_ssize_t type is large enough to represente positive infinites, then you probably could support infinite range objects. Regards Antoine.

On Feb 1, 2015 9:48 PM, "Antoine Pitrou" wrote:

On Mon, 2 Feb 2015 07:38:52 +1100 Chris Angelico wrote:

...

On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver

...

...

Iterating over a slice object would work like you were lazily taking

wrote: that

...

...

slice from itertools.count() - i.e. iter(a:b:c) would be equivalent to islice(count(), a, b, c). This would also mean that (3:) would have a logical meaning without having to modify range objects to support an optional upper bound. I don't see any logical way to iterate over a slice defined with negative numbers (e.g. (-4:)), so presumably iter(-4:) would raise an exception.

If you're going to start defining things in terms of itertools.count(), I'd prefer to first permit a range object to have an infinite upper bound, and then define everything in terms of a sliced range - range objects already support clean slicing.

Is there any particular reason for range objects to disallow infinite bounds, or is it just that nobody's needed it?

If the platform's Py_ssize_t type is large enough to represente positive infinites, then you probably could support infinite range objects.

Or you could just make a special case if the upper bound is None. The question is what would happen if you tried to get the len() of such a range. An exception? -1? None?

On Feb 1, 2015 7:14 PM, "Thomas Kluyver" wrote:

On 1 February 2015 at 07:13, Todd wrote:

...

For examples, the following pairs are equivalent:

range(4, 10, 2) (4:10:2)

I think I remember a proposal somewhere to allow slice notation (defining

slice objects) outside of [] indexing. That would conflict with this idea of having slice notation define range objects. However, if slice notation defined slice objects and slice objects were iterable, wouldn't that have the same benefits?

Edit: apparently this email was cut off for at least some people, so I am resending it. If you got the full email adjust you can disregard this one. I considered the idea of making slices iterable. I thought of three scenarios (in the following order): Slice is iterable: this has the advantage that classes implementing slicing could just iterate over any slice they get. The problem here is that you end up with two data structures with separate implementations but nearly identical functionality. This would be unnecessary code duplication and thus, I felt, unlikely to be accepted. Slice is a subclass of range: this avoids the problem of the independent implementations. The problem is that it would be a subclass in name only. I could not think if any additional methods or attributes it should have compared to conventional ranges. The only thing it would do that ranges currently can't is not have an end, but since that would need to be implemented somewhere it might as well be added to the range parent class. So I felt that would be a deal-killer. Use slices to make ranges: this would not be as useful in classes, but it would really only save one line at best. It has the advantage that it would not require ranges to support anything they can't already. Although you could support infinite ranges, you could just as easily just not accept open-ended slices. Since the first two cases essentially reduce to the third, I felt the third approach would be the most straightforward. I also considered two other, related issues: Using a slice object with this syntax. However, something like (slice_obj) seemed like it could break existing code, and (:slice_obj) just seemed weird. Passing a slice to a range. So you could do range(slice_obj), but this seems like something that would have very little benefit and only save a little account of code.

On Sun, Feb 1, 2015 at 10:51 PM, Greg Ewing wrote:

Todd wrote:

...

Although slices and ranges are used for different things and implemented differently, conceptually they are similar: they define an integer sequence with a start, stop, and step size.

They behave differently in some ways, though. Consider:

...

...

...

list(range(9,-1,-1)) [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

But:

...

...

...

x = list(range(10)) x [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] x[9:-1:-1] []

Would your proposed slice-ranges behave like slices or ranges in this situation? And how will people remember which?

Since this is really a literal for making ranges, I would say the range syntax would be the correct one. As I replied to Steven, let's forget the idea that slices and ranges are the same. I was mistaken about that. Let's just call this a range literal. It has some features similar to slices, but not all.

On Mon, Feb 2, 2015 at 1:48 PM, Paul Moore wrote:

On 2 February 2015 at 10:22, Todd wrote:

...

Let's just call this a range literal. It has some features similar to slices, but not all.

So what would d[1:10:2] mean? d[Slice(1,10,2)] or d[range(1,10,2)]?

At the moment 1:10:2 is a slice literal, and you're proposing to repurpose it as a range literal? What have I missed? Because that's never going to satisfy backward compatibility requirements.

No, I am proposing that (x:y:x) is syntactic sugar for range(x, y, z). Note the parentheses. Currently wrapping slice notation in a parentheses is not valid syntax, so there is no backwards-compatibility issues. Bare slice notation, without the parentheses or in an index, will remain invalid syntax. I am absolutely *not* proposing that anything change with existing slices. d[1:10:2] would not change at all. d[(1:10:2)] would become valid syntax, but it is not the use-case that prompted it and I doubt anyone would actually want to do that. I am more interested in something like: for i in (1:10:2): pass I am also *not* proposed the following syntax, since it would be ambiguous in many cases: for i in 1:10:2: pass

On Mon, Feb 2, 2015 at 11:03 AM, Nick Coghlan wrote:

On 2 Feb 2015 01:14, "Todd" wrote:

...

Although slices and ranges are used for different things and implemented

differently, conceptually they are similar: they define an integer sequence with a start, stop, and step size. For this reason I think that slices could provide useful syntactic sugar for defining ranges without sacrificing clarity.

Why is this beneficial? We'd be replacing an easily looked up builtin name with relatively cryptic syntax.

First, it wouldn't be a replacement. The existing range syntax would still exist. But the reason it is beneficial is the same reason we have [a, b, c] for list, {a:1, b:2, c:3} for dicts, {a, b, c} for sets, and (a, b, c) for tuples. It is more compact way to create a commonly-used data structure. And I wouldn't consider it any more cryptic than any other literal we have.

On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico wrote:

On Mon, Feb 2, 2015 at 9:26 PM, Todd wrote:

...

First, it wouldn't be a replacement. The existing range syntax would still exist.

But the reason it is beneficial is the same reason we have [a, b, c] for list, {a:1, b:2, c:3} for dicts, {a, b, c} for sets, and (a, b, c) for tuples. It is more compact way to create a commonly-used data structure.

And I wouldn't consider it any more cryptic than any other literal we have.

Considering the single most common use of ranges, let's see how a for loop would look:

for i in 1:10: pass

Is that nastily cryptic, or beautifully clean? I'm inclined toward the former, but could be persuaded.

It would be for i in (1:10): pass Anyone who uses sequences should be familiar with this sort of notation: for i in spam[1:10]: pass So should have at least some understanding that 1:10 can mean "1 to 10, not including 10". I don't see it being any more cryptic than {'a': 1, 'b': 2} meaning dict(a=1, b=2). On the contrary, I think the dict literal syntax is even more cryptic, since it has no similarity to any other syntax. The syntax I propose here is at least similar (although not identical) to slicing.

On Mon, Feb 02, 2015 at 12:10:32PM +0000, Rob Cliffe wrote:

Having said that, I would have a sneaking admiration for a really concise syntax.

I'm partial to for i in 1...10: pass myself. -- Steve

On Mon, Feb 2, 2015 at 1:10 PM, Rob Cliffe wrote:

On 02/02/2015 11:19, Todd wrote:

On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico wrote:

...

On Mon, Feb 2, 2015 at 9:26 PM, Todd wrote:

...

First, it wouldn't be a replacement. The existing range syntax would still exist.

But the reason it is beneficial is the same reason we have [a, b, c] for list, {a:1, b:2, c:3} for dicts, {a, b, c} for sets, and (a, b, c) for tuples.

Well, we have to have *some* syntax for literal lists, dicts etc. But we already have range, so there is no compelling need to add new syntax.

Why do we need literals at all? They are just syntactic sugar. Python went a long time without a set literal.

Having said that, I would have a sneaking admiration for a really concise syntax. Perhaps if we had "Python without colons", we could write for i in 1 : 10 for i in 1 : 10 : 2

Part of my goal was to avoid any ambiguity with any existing syntax. Since we do have colons in for loops, I felt that some sort of grouping (either [], {}, or ()) was necessary to avoid ambiguity.

L = ['foo', 'bar', 'baz'] is syntactic sugar, you can write L = list('foo', 'bar', 'baz') On 2 February 2015 at 13:43, Rob Cliffe wrote:

On 02/02/2015 12:38, Todd wrote:

On Mon, Feb 2, 2015 at 1:10 PM, Rob Cliffe wrote:

...

On 02/02/2015 11:19, Todd wrote:

On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico wrote:

...

On Mon, Feb 2, 2015 at 9:26 PM, Todd wrote:

...

First, it wouldn't be a replacement. The existing range syntax would still exist.

But the reason it is beneficial is the same reason we have [a, b, c] for list, {a:1, b:2, c:3} for dicts, {a, b, c} for sets, and (a, b, c) for tuples.

Well, we have to have *some* syntax for literal lists, dicts etc. But we already have range, so there is no compelling need to add new syntax.

Why do we need literals at all? They are just syntactic sugar. Python went a long time without a set literal.

Well, if you'd rather write L = list() L.add('foo') L.add('bar') L.add('baz') than L = ['foo', 'bar', 'baz'] then good luck to you.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

It would be

for i in (1:10): pass

Anyone who uses sequences should be familiar with this sort of notation:

for i in spam[1:10]: pass

So should have at least some understanding that 1:10 can mean "1 to 10, not including 10".

I don't see it being any more cryptic than {'a': 1, 'b': 2} meaning dict(a=1, b=2). On the contrary, I think the dict literal syntax is even more cryptic, since it has no similarity to any other syntax. The syntax I

If you can spare one character you can define a function similar to take that takes a slice object as agreement. Then call it like: for i in I(1:10): # do stuff No change in syntax needed, probably 6 lines in the function definition. I chose 'I' for Integers, and because it looks small. You could use a different one letter name. propose here is at least similar (although not identical) to slicing.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/