With generators in the language, should xrange be deprecated? Skip
With generators in the language, should xrange be deprecated?
Skip
No, but maybe xrange() should be changed to return an iterator. E.g. something like this: def xrange(start, stop, step): while start < stop: yield start start += stop but with the appropriate defaults, and reversal of the test if step < 0, and an error if step == 0, and type checks enforcing ints (or long ints!), and implemented in C. :-) Although xrange() objects currently support some sequence algebra, that is mostly bogus and I don't think anyone in their right mind uses it. --Guido van Rossum (home page: http://www.python.org/~guido/)
With generators in the language, should xrange be deprecated?
Skip
No, but maybe xrange() should be changed to return an iterator. E.g. something like this:
def xrange(start, stop, step): while start < stop: yield start start += stop
but with the appropriate defaults, and reversal of the test if step < 0, and an error if step == 0, and type checks enforcing ints (or long ints!), and implemented in C. :-)
Although xrange() objects currently support some sequence algebra, that is mostly bogus and I don't think anyone in their right mind uses it. I _was_ using xrange as sets representing (potentially large) ranges of ints. Example:
positive = xrange(1, sys.maxint) if num in positive: ... I didt follow the iterators discussion: would this continue to work? Thomas
[me]
Although xrange() objects currently support some sequence algebra, that is mostly bogus and I don't think anyone in their right mind uses it.
[theller]
I _was_ using xrange as sets representing (potentially large) ranges of ints. Example:
positive = xrange(1, sys.maxint)
if num in positive: ...
I didt follow the iterators discussion: would this continue to work?
No, it would break. And I see another breakage too: r = xrange(10) for i in r: for j in r: print i, j would not do the right thing if xrange() returned an iterator (because iterators can only be used once). This is too bad; I really wish that xrange() could die or be limited entirely to for loops. I wonder if we could put warnings on xrange() uses beyond the most basic...? --Guido van Rossum (home page: http://www.python.org/~guido/)
[theller]
I _was_ using xrange as sets representing (potentially large) ranges of ints. Example:
positive = xrange(1, sys.maxint)
if num in positive: ...
I didt follow the iterators discussion: would this continue to work?
No, it would break. Since there was a off-by-one bug for 'if num in xrange()' in Pyhon2.0 my code already has been rewritten.
Thomas
[Thomas Heller]
I _was_ using xrange as sets representing (potentially large) ranges of ints. Example:
positive = xrange(1, sys.maxint)
if num in positive: ... I didt follow the iterators discussion: would this continue to work?
[Guido]
No, it would break.
"x in y" works with any iterable y in 2.2, incl. generators. So e.g.
def xr(n): ... i = 0 ... while i < n: ... yield i ... i += 1 ... 1 in xr(10) 1 9 in xr(10) 1 10 in xr(10) 0
However, there's no __contains__ method here, so in the last case it actually did 10 compares. 0 in xr(sys.maxint) is very quick, but I'm still waiting for -1 in xr(sys.maxint) to complete <wink>.
And I see another breakage too:
This would also apply to Thomas's example of giving a name to an xrange object, if implemented via generator:
small = xr(5) 2 in small 1 2 in small 0
... This is too bad; I really wish that xrange() could die or be limited entirely to for loops. I wonder if we could put warnings on xrange() uses beyond the most basic...?
Hmm. I'd rather not endure the resulting complaints without a strong rationale for deprecating it. One that strikes close to my heart: there's more code in 2.2 to support xrange than there is to support generators! But users don't care about that.
Hmm. I'd rather not endure the resulting complaints without a strong rationale for deprecating it. One that strikes close to my heart: there's more code in 2.2 to support xrange than there is to support generators! But users don't care about that.
But I do, and historically this code has often been bug-ridden without anybody noticing -- so it's not like it's needed much. I would suggest to remove most of the fancy features of xrange(), in particular the slice, contains and repeat slots. A step further would be to remove getitem also, and add a tp_getiter slot instead -- returning not itself but a new iterator that iterates through the prescribed sequence. We need a PEP for this. Anyone? Should be short and sweet. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Jun 25, 2001 at 10:47:50AM -0400, Guido van Rossum wrote: [ xrange can't be changed into a generator ]
This is too bad; I really wish that xrange() could die or be limited entirely to for loops. I wonder if we could put warnings on xrange() uses beyond the most basic...?
Why do we want to do this ? xrange() is still exactly what it was: an object
that pretends to be a list of integers. Besides being useful for those who
work a lot with ranges, it's a wondeful example on what you can do with
Python (even if it isn't actually written in Python :-)
I see less reason to deprecate xrange than to deprecate the gopherlib,
wave/aifc/audiodev, mhlib, netrc and/or robotparser modules.
--
Thomas Wouters
[ xrange can't be changed into a generator ]
This is too bad; I really wish that xrange() could die or be limited entirely to for loops. I wonder if we could put warnings on xrange() uses beyond the most basic...?
Why do we want to do this ? xrange() is still exactly what it was: an object that pretends to be a list of integers. Besides being useful for those who work a lot with ranges, it's a wondeful example on what you can do with Python (even if it isn't actually written in Python :-)
There is exactly *one* idiomatic use of xrange(): for i in xrange(...): ... All other operations supported by the xrange object are very rarely used, and historically their implementation has had obvious bugs that no-one noticed for years.
I see less reason to deprecate xrange than to deprecate the gopherlib, wave/aifc/audiodev, mhlib, netrc and/or robotparser modules.
Those are useful application-area libraries for some folks. The idiomatic xrange() object is useful too. But the advanced features of xrange() are an example of code bloat. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
Although xrange() objects currently support some sequence algebra, that is mostly bogus and I don't think anyone in their right mind uses it.
I agree. As long as we make those cases fail loudly, I see no objection to dropping support for them. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Americans have the will to resist because you have weapons. If you don't have a gun, freedom of speech has no power. -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992
participants (6)
-
Eric S. Raymond -
Guido van Rossum -
Skip Montanaro -
Thomas Heller -
Thomas Wouters -
Tim Peters