[Python-Dev] best practices stdlib: purging xrange (original) (raw)
Guido van Rossum guido at python.org
Tue May 8 16:04:08 CEST 2007
- Previous message: [Python-Dev] best practices stdlib: purging xrange
- Next message: [Python-Dev] best practices stdlib: purging xrange
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/8/07, Armin Rigo <arigo at tunes.org> wrote:
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote: > 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.
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?
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/)
- Previous message: [Python-Dev] best practices stdlib: purging xrange
- Next message: [Python-Dev] best practices stdlib: purging xrange
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]