I'd like to suggest that we remove all (or nearly all) uses of xrange from the stdlib. A quick scan shows that most of the usage of it is unnecessary. With it going away in 3.0, and it being informally deprecated anyway, it seems like a good thing to go away where possible. Any objections? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
But why bother? The 2to3 converter can do this for you. In a sense using range() is more likely to produce broken results in 3.0: if your code depends on the fact that range() returns a list, it is broken in 3.0, and 2to3 cannot help you here. But if you use list(xrange()) today, the converter will turn this into list(range()) in 3.0 and that will continue to work correctly. --Guido On 5/7/07, Anthony Baxter <anthony@interlink.com.au> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido van Rossum" <guido@python.org> wrote in message news:ca471dc20705071703p54a9afc3yfe9693c5fe6e2f23@mail.gmail.com... | But why bother? The 2to3 converter can do this for you. | | In a sense using range() is more likely to produce broken results in | 3.0: if your code depends on the fact that range() returns a list, it | is broken in 3.0, and 2to3 cannot help you here. But if you use | list(xrange()) today, the converter will turn this into list(range()) | in 3.0 and that will continue to work correctly. Just curious why 2to3 would not replace range() with list(range())? tjr
On 5/7/07, Terry Reedy <tjreedy@udel.edu> wrote:
That's a good idea. But I'd like someone else to implement it... -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Just curious why 2to3 would not replace range() with list(range())?
In most usages of range(), using the 3.0 range() will work just as well, and be more efficient. If I wanted to write code that works in both versions (which I understand is not the 2to3 objective), then I would use range(). If I worry about creating a list in 2.x, I would write try: xrange except NameError: xrange=range at the top of the file. Regards, Martin
""Martin v. Löwis"" <martin@v.loewis.de> wrote in message news:4641523A.2070106@v.loewis.de... |> Just curious why 2to3 would not replace range() with list(range())? | | In most usages of range(), using the 3.0 range() will work just as | well, and be more efficient. If so, which it would seem from range2x functionally equal to list(range3), then the suggestion of the subject line is backwards. What should be purged eventually is range in for statement headers (or list(range) after conversion). It seems that what some consider best practice now (make a list unless it is long and un-needed) is different from what will be best practice in Py3 (do not make a list unless actually need it). tjr
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
Punt it when it's no longer useful (py3k); xrange exists for a reason- most usage just needs to iterate over a range of numbers (xrange), not instantiate a list of the range, then iterate over said range (range). Don't much see the point in making stdlib more wasteful in runtime for an "informally deprecated" func that lots of folks in the real world still use. ~brian
Hi Anthony, On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
The first step is to focus the question on the places where replacing xrange() with range() can really make no difference at all, as far as we can see. This is not the case of "nearly all" the uses of xrange() from the stdlib - but it's still the case of a number of them: ''.join(chr(x) for x in xrange(256)) # at global module level or: for i in xrange(self.firstweekday, self.firstweekday + 7): I personally think that replacing these with range() is a clean-up, but I also know that not everybody agrees to that. So: should we, or should we not, replace xrange() with range() as a matter of clean-up when the difference between the two is really completely irrelevant? A bientot, Armin.
On 5/8/07, Armin Rigo <arigo@tunes.org> wrote:
I'm all for that -- personally, I wouldn't have written xrange() in the first place in such cases! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On May 8, 2007, at 8:49 AM, Armin Rigo wrote:
But doesn't doing this now this make the conversion to Py3 *harder*? If 2to3 is going to rewrite xrange() as range(), and range() to list (range()), then moving towards xrange where possible would actually be preferable, wouldn't it? Or is there no plan to run 2to3 on the stdlib? James
* James Y Knight <foom@fuhm.net> [2007-05-08 11:18:44]:
Looking at xrange() and range() definitions and from this discussion, it seems to me that xrange() to be preferable over range(). Its common that most of the code have range() because its simple use in iteration, but if same functionality is provided with xrange as an object. And doing :s/xrange/range/g would make sense also. ( Am I right in understanding this?) Why range or xrange and why not xrange or range? Or is this discussion about why having two functions with similar (or rather same) functionality, and lets move to one and in which case either of them is fine. -- O.R.Senthil Kumaran
But why bother? The 2to3 converter can do this for you. In a sense using range() is more likely to produce broken results in 3.0: if your code depends on the fact that range() returns a list, it is broken in 3.0, and 2to3 cannot help you here. But if you use list(xrange()) today, the converter will turn this into list(range()) in 3.0 and that will continue to work correctly. --Guido On 5/7/07, Anthony Baxter <anthony@interlink.com.au> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido van Rossum" <guido@python.org> wrote in message news:ca471dc20705071703p54a9afc3yfe9693c5fe6e2f23@mail.gmail.com... | But why bother? The 2to3 converter can do this for you. | | In a sense using range() is more likely to produce broken results in | 3.0: if your code depends on the fact that range() returns a list, it | is broken in 3.0, and 2to3 cannot help you here. But if you use | list(xrange()) today, the converter will turn this into list(range()) | in 3.0 and that will continue to work correctly. Just curious why 2to3 would not replace range() with list(range())? tjr
On 5/7/07, Terry Reedy <tjreedy@udel.edu> wrote:
That's a good idea. But I'd like someone else to implement it... -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Just curious why 2to3 would not replace range() with list(range())?
In most usages of range(), using the 3.0 range() will work just as well, and be more efficient. If I wanted to write code that works in both versions (which I understand is not the 2to3 objective), then I would use range(). If I worry about creating a list in 2.x, I would write try: xrange except NameError: xrange=range at the top of the file. Regards, Martin
""Martin v. Löwis"" <martin@v.loewis.de> wrote in message news:4641523A.2070106@v.loewis.de... |> Just curious why 2to3 would not replace range() with list(range())? | | In most usages of range(), using the 3.0 range() will work just as | well, and be more efficient. If so, which it would seem from range2x functionally equal to list(range3), then the suggestion of the subject line is backwards. What should be purged eventually is range in for statement headers (or list(range) after conversion). It seems that what some consider best practice now (make a list unless it is long and un-needed) is different from what will be best practice in Py3 (do not make a list unless actually need it). tjr
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
Punt it when it's no longer useful (py3k); xrange exists for a reason- most usage just needs to iterate over a range of numbers (xrange), not instantiate a list of the range, then iterate over said range (range). Don't much see the point in making stdlib more wasteful in runtime for an "informally deprecated" func that lots of folks in the real world still use. ~brian
Hi Anthony, On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
The first step is to focus the question on the places where replacing xrange() with range() can really make no difference at all, as far as we can see. This is not the case of "nearly all" the uses of xrange() from the stdlib - but it's still the case of a number of them: ''.join(chr(x) for x in xrange(256)) # at global module level or: for i in xrange(self.firstweekday, self.firstweekday + 7): I personally think that replacing these with range() is a clean-up, but I also know that not everybody agrees to that. So: should we, or should we not, replace xrange() with range() as a matter of clean-up when the difference between the two is really completely irrelevant? A bientot, Armin.
On 5/8/07, Armin Rigo <arigo@tunes.org> wrote:
I'm all for that -- personally, I wouldn't have written xrange() in the first place in such cases! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On May 8, 2007, at 8:49 AM, Armin Rigo wrote:
But doesn't doing this now this make the conversion to Py3 *harder*? If 2to3 is going to rewrite xrange() as range(), and range() to list (range()), then moving towards xrange where possible would actually be preferable, wouldn't it? Or is there no plan to run 2to3 on the stdlib? James
* James Y Knight <foom@fuhm.net> [2007-05-08 11:18:44]:
Looking at xrange() and range() definitions and from this discussion, it seems to me that xrange() to be preferable over range(). Its common that most of the code have range() because its simple use in iteration, but if same functionality is provided with xrange as an object. And doing :s/xrange/range/g would make sense also. ( Am I right in understanding this?) Why range or xrange and why not xrange or range? Or is this discussion about why having two functions with similar (or rather same) functionality, and lets move to one and in which case either of them is fine. -- O.R.Senthil Kumaran
participants (8)
-
"Martin v. Löwis" -
Anthony Baxter -
Armin Rigo -
Brian Harring -
Guido van Rossum -
James Y Knight -
O.R.Senthil Kumaran -
Terry Reedy