Re: [Python-Dev] Inclusive Range
On 2010-10-04, at 05:04 , Eviatar Bach wrote: > Hello, > > I have a proposal of making the range() function inclusive; that is, > range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only > is it more intuitive, it also seems to be used often, with coders often > writing range(0, example+1) to get the intended result. It would be easy to > implement, and though significant, is not any more drastic than changing > print to a function in Python 3. Of course, if this were done, slicing > behaviour would have to be adjusted accordingly. > > What are your thoughts? Same as the others: 0. This is a discussion for python-ideas, I'm CCing that list 1. This is a major backwards compatibility breakage, and one which is entirely silent (`print` from keyword to function wasn't) 2. It loses not only well-known behavior but interesting properties as well (`range(n)` has exactly `n` elements. With your proposal, it has ``n+1`` breaking ``for i in range(5)`` to iterate 5 times as well as ``for i in range(len(collection))`` for cases where e.g. ``enumerate`` is not good enough or too slow) 3. As well as the relation between range and slices 4. I fail to see how it is more intuitive (let alone more practical, see previous points) 5. If you want an inclusive range, I'd recommend proposing a flag on `range` (e.g. ``inclusive=True``) rather than such a drastic breakage of ``range``'s behavior. That, at least, might have a chance. Changing the existing default behavior of range most definitely doesn't. I'd be −1 on your proposal, −0 on adding a flag to ``range`` (I can't recall the half-open ``range`` having bothered me recently, if ever) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inclusive Range
On 03Oct2010 20:04, Eviatar Bach wrote: | I have a proposal of making the range() function inclusive; that is, | range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only | is it more intuitive, it also seems to be used often, with coders often | writing range(0, example+1) to get the intended result. It would be easy to | implement, and though significant, is not any more drastic than changing | print to a function in Python 3. Of course, if this were done, slicing | behaviour would have to be adjusted accordingly. 1: take this to python-ieas please instead of python-dev. 2: -1; the current behaviour is, IMHO, highly desirable. Example: x=3; y=7; z=12 s='ahahahahahahahaha' assert s[:x]+s[x:y]+s[y:z]+s[z:] == s No icky +1 hacks in there. 3: I find myself doing the +1 thing very _un_often, myself. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ The hardest years in life are those between ten and seventy. - Helen Hayes (at age 84) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inclusive Range
2010/10/3 Eviatar Bach : > Hello, > > I have a proposal See the python-ideas mailing list. > of making the range() function inclusive; that is, > range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only > is it more intuitive, it also seems to be used often, with coders often > writing range(0, example+1) to get the intended result. It would be easy to > implement, and though significant, is not any more drastic than changing > print to a function in Python 3.. Yes, it is. It's much more subtle. > > What are your thoughts? Completely backwards incompatible. -1 -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Inclusive Range
Hello, I have a proposal of making the range() function inclusive; that is, range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only is it more intuitive, it also seems to be used often, with coders often writing range(0, example+1) to get the intended result. It would be easy to implement, and though significant, is not any more drastic than changing print to a function in Python 3. Of course, if this were done, slicing behaviour would have to be adjusted accordingly. What are your thoughts? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
