More useful slices
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. The syntax I propose is simply to wrap a slice in parentheses. For examples, the following pairs are equivalent: range(4, 10, 2) (4:10:2) range(3, 7) (3:7) range(5) (:5) This syntax should not be easily confused with any existing syntax. Slices of sequences use square brackets, dictionaries use curly braces, and function annotations only appear in function declarations. It is also considerably more compact than the current range syntax, while still being similar to a syntax (slicing) all python users should be familiar with.
On Sun, Feb 1, 2015 at 10:13 AM, Todd <toddrjen@gmail.com> 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.
The syntax I propose is simply to wrap a slice in parentheses. For examples, the following pairs are equivalent:
range(4, 10, 2) (4:10:2)
range(3, 7) (3:7)
range(5) (:5)
This syntax should not be easily confused with any existing syntax. Slices of sequences use square brackets, dictionaries use curly braces, and function annotations only appear in function declarations. It is also considerably more compact than the current range syntax, while still being similar to a syntax (slicing) all python users should be familiar with.
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] which produces a list instead of a range object. Other than for completeness this does not seem very useful, though. Eugene
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. -- Greg
On Sun, Feb 1, 2015 at 10:51 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> 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 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
On 2015-02-01, at 18:27 , Steven D'Aprano <steve@pearwood.info> 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 Feb 1, 2015 6:27 PM, "Steven D'Aprano" <steve@pearwood.info> 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.
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.
On Sun, Feb 01, 2015 at 10:18:33PM +0100, Todd wrote:
On Feb 1, 2015 6:27 PM, "Steven D'Aprano" <steve@pearwood.info> 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
On Mon, Feb 2, 2015 at 2:36 AM, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Feb 01, 2015 at 10:18:33PM +0100, Todd wrote:
On Feb 1, 2015 6:27 PM, "Steven D'Aprano" <steve@pearwood.info> 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.
Then let's ignore the original justification, and say this is just a syntax for making ranges that is similar to, but not identical to, slices.
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/
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). On Monday, February 2, 2015 at 10:01:34 AM UTC-5, 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 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 <mistersheik@gmail.com> 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<stop; i+=step) { do something interesting with 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
On 02/02/2015 18:00, Skip Montanaro wrote:
On Mon, Feb 2, 2015 at 9:29 AM, Neil Girdhar <mistersheik@gmail.com> 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<stop; i+=step) { do something interesting with 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
You (plural) can debate this until the cows come home, but as the BDFL rejected it a couple of hours ago it strikes me as an all round waste of time and bandwidth. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Mon, Feb 2, 2015 at 10:00 AM, Skip Montanaro <skip.montanaro@gmail.com> 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<stop; i+=step) { do something interesting with 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
On Mon, Feb 2, 2015 at 12:46 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Mon, Feb 2, 2015 at 10:00 AM, Skip Montanaro <skip.montanaro@gmail.com> 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 ;-)
I wasn't arguing for its inclusion, just explaining that there is potentially more than a few characters of typing to be saved. (Someone asked if that was the only benefit of the proposal.) FWIW, at least some compilers (Shed Skin, I believe, perhaps Cython and/or Pyrex as well) already treat range() as a builtin constant. Skip
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<stop; i+=step) { do something interesting with 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
On 02/02/2015 22:25, Greg Ewing wrote:
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<stop; i+=step) { do something interesting with 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.
I like it! Much clearer than any other suggested syntax. Flexible: Allows closed or open ends, whichever is more convenient or better style. Unambiguous: 'for' not followed by non-nested 'in' is currently not valid syntax. Efficient: allows faster bytecode to be generated. +1 Rob Cliffe
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 <mistersheik@gmail.com> 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/
I don't want to have to have a log drawn-out argument over why I don't like this proposal or PEP 204. For every reason I can bring up there will surely be someone who strongly disagrees with that reason. But I'm still going to reject it -- we already have range() and slice(), with their subtle but irreconcilable differences, and neither of them is important enough to warrant any more support built into the language. On Mon, Feb 2, 2015 at 8:11 AM, 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.
-Chris
On Feb 2, 2015, at 7:02 AM, Neil Girdhar <mistersheik@gmail.com> 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 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/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
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, Feb 2, 2015 at 8:11 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
It would be nice if there was more Kongo as to why it was rejected,
Wow -- weird auto-correct! That was supposed to be "info". That's what I get for trying to write these notes on a phone on the bus... Sorry, -Chris
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 <mistersheik@gmail.com> 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 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/
-- 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
On 1 February 2015 at 07:13, Todd <toddrjen@gmail.com> 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? 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. Thomas
On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver <thomas@kluyver.me.uk> 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? ChrisA
On Mon, 2 Feb 2015 07:38:52 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver <thomas@kluyver.me.uk> 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 Mon, Feb 2, 2015 at 7:46 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
If the platform's Py_ssize_t type is large enough to represente positive infinites, then you probably could support infinite range objects.
*headscratch* You're asking if a native integer type can represent infinity? What kind of computers do you think we have here? Actual Turing machines? ChrisA
On Feb 1, 2015 9:48 PM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
On Mon, 2 Feb 2015 07:38:52 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver <thomas@kluyver.me.uk>
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" <thomas@kluyver.me.uk> wrote:
On 1 February 2015 at 07:13, Todd <toddrjen@gmail.com> 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
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
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? I considered that. 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. 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.
Thomas
I though
On Feb 1, 2015 7:14 PM, "Thomas Kluyver" <thomas@kluyver.me.uk> wrote:
On 1 February 2015 at 07:13, Todd <toddrjen@gmail.com> 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.
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? -- Greg
On Sun, Feb 1, 2015 at 10:51 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> 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 2 February 2015 at 10:22, Todd <toddrjen@gmail.com> 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. Paul
On Mon, Feb 2, 2015 at 1:48 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 2 February 2015 at 10:22, Todd <toddrjen@gmail.com> 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 2 Feb 2015 01:14, "Todd" <toddrjen@gmail.com> 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. There's also the fact that "slice" itself is a builtin, so it's entirely unclear that standalone usage of the slice syntax (if it was ever permitted at all) should produce a range object instead of a slice object. Regards, Nick.
On Mon, Feb 2, 2015 at 11:03 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 2 Feb 2015 01:14, "Todd" <toddrjen@gmail.com> 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 9:26 PM, Todd <toddrjen@gmail.com> 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. ChrisA
On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen@gmail.com> 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 02/02/2015 11:19, Todd wrote:
On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:
On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen@gmail.com <mailto:toddrjen@gmail.com>> 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. 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
I'm partial to
for i in 1...10: pass
myself.
You have to handle step size != 1 in the loop. I'm +0 on the whole idea of repurposing/creating syntax for range(). On the one hand, I think the syntactic sugar can be kind of handy, and runtime optimization of loop constructs is likely to be a bit better. OTOH, I doubt the presence of a call to range() vs. a fixed chunk of syntax is a big impediment to the PyPy folks and others interested in optimizing Python performance. Skip
On Mon, Feb 2, 2015 at 1:10 PM, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
On 02/02/2015 11:19, Todd wrote:
On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen@gmail.com> 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.
On Mon, Feb 2, 2015 at 1:10 PM, Rob Cliffe <rob.cliffe@btinternet.com <mailto:rob.cliffe@btinternet.com>> wrote:
On 02/02/2015 11:19, Todd wrote:
On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:
On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen@gmail.com <mailto:toddrjen@gmail.com>> 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')
On 02/02/2015 12:38, Todd wrote: than L = ['foo', 'bar', 'baz'] then good luck to you.
L = ['foo', 'bar', 'baz'] is syntactic sugar, you can write L = list('foo', 'bar', 'baz') On 2 February 2015 at 13:43, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
On 02/02/2015 12:38, Todd wrote:
On Mon, Feb 2, 2015 at 1:10 PM, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
On 02/02/2015 11:19, Todd wrote:
On Mon, Feb 2, 2015 at 11:53 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen@gmail.com> 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/
On 02/02/2015 12:48, João Santos wrote:
L = ['foo', 'bar', 'baz'] is syntactic sugar, you can write L = list('foo', 'bar', 'baz') No you can't (at least not in Python 2.7.3). (A good advertisement for testing your code before publishing it. ) It has to be L = list(('foo', 'bar', 'baz')) which is using a tuple literal.
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/
On 2 Feb 2015 21:00, "Chris Angelico" <rosuav@gmail.com> wrote:
On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen@gmail.com> 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.
Some additional historical context, found while looking for range literal notations in other languages: PEP 204 is a previously rejected proposal for range literals (https://www.python.org/dev/peps/pep-0204/) If you'd like to propose a range literal, you may be better off steering clear of slice notation and instead look to other languages like Ruby or Haskell for inspiration (slice notation may still be useful for appending a step to the range definition). Such an idea will likely still be rejected in the absence of compelling use cases though, especially as direct iteration over a container or using the enumerate builtin is often going to be superior to creating a range object. That makes it very difficult to justify the cost of invalidating all of the existing documentation on how to create ranges in Python. Regards, Nick.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (19)
-
Antoine Pitrou -
Chris Angelico -
Chris Barker -
Chris Barker - NOAA Federal
-
David Mertz -
Eugene Toder -
Greg Ewing -
Guido van Rossum -
João Santos -
Mark Lawrence -
Masklinn -
Neil Girdhar -
Nick Coghlan -
Paul Moore -
Rob Cliffe -
Skip Montanaro -
Steven D'Aprano -
Thomas Kluyver -
Todd