xsrange is not an iterator when called with Python ints or longs

[sagetrac-tmonteil]

As reported in this ask question, there is a problem with ellipsis_iter:

sage: r = lambda n: (n-(n%2))//2
sage: for n in range(6):
....:     print([r(n-k) + r(n+k) for k in (-n..n)])
AttributeError: 'xrange' object has no attribute 'next'

This is due to the fact that, while xsrange claims to return an iterator, it does not provide a .next() method when called with Python ints or longs:

sage: xsrange(int(42)).next()
AttributeError: 'xrange' object has no attribute 'next'

This is because in those cases, it returns an xrange object (which is only an iterable).

Component: misc

Branch/Commit: u/tmonteil/xsrange_is_not_an_iterator_when_called_with_python_ints_or_longs @ 9101119

Reviewer: Jeroen Demeyer

Issue created by migration from https://trac.sagemath.org/ticket/18538

[sagetrac-tmonteil]

Branch: u/tmonteil/xsrange_is_not_an_iterator_when_called_with_python_ints_or_longs

[sagetrac-git]

Commit: 4a59f33

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

4a59f33

#18538 : remove redundency in linking to trac ticket.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

91c1b9c

#18538 : add the original example as doctest.

[sagetrac-git]

Changed commit from 4a59f33 to 91c1b9c

[sagetrac-tmonteil]

Author: Thierry Monteil

[a-andre]

comment:7

Please replace next() method by next() function. See #17398.

[sagetrac-git]

Changed commit from 91c1b9c to 9101119

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

9101119

#18538 Python3 compatibility.

[videlec]

comment:10

Hello,

Why xsrange should have a next method?

sage: next(xrange(10))
Traceback (most recent call last):
...
TypeError: xrange object is not an iterator

I think that we should keep compatibility between xsrange and xrange.

Vincent

[jdemeyer]

comment:11

I also think it's better to use iter(foo) instead of foo.__iter__().

[jdemeyer]

comment:12

This:

``.next()`` or a ``.__next__()`` method

should be replaced by

``.__next__()`` method

But even then, I find it a bit confusing that you talk about a __next__ method and then show two tests not explicitly involving __next__

[jdemeyer]

comment:13

Fixed by #20094 instead (which removes the special cases for Python int).

[jdemeyer]

Changed author from Thierry Monteil to none

[jdemeyer]

Reviewer: Jeroen Demeyer