Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Sadly so high numbers are longs and xrange seems to get an integer.
Something like that, yes: the start, step and length of an xrange object
are stored internally as C longs (just as Python ints are), and this is
unlikely to change.
The
Diego <[EMAIL PROTECTED]> added the comment:
>>> a = xrange(2**32)
Traceback (most recent call last):
File "", line 1, in
OverflowError: long int too large to convert to int
>>> 2**32
4294967296L
>>> a=range(2**32)
Traceback (most recent call last):
File "", line 1, in
OverflowError: range(
Diego <[EMAIL PROTECTED]> added the comment:
2008/8/6 Mark Dickinson <[EMAIL PROTECTED]>:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> By the way, do you already know about xrange?
>
> xrange([start,] stop[, step]) -> xrange object
>
> Like range(), but instead of returning a lis
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
By the way, do you already know about xrange?
xrange([start,] stop[, step]) -> xrange object
Like range(), but instead of returning a list, returns an object that
generates the numbers in the range on demand. For looping, this is
slightly
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The behavior of range is very unlikely to be changed in Python 2.x, for
backwards compatibility reasons.
But it's a great idea! So great, in fact, that it's already been
implemented for Python 3.0. :-) There range() behaves like a genera
Ezio Melotti <[EMAIL PROTECTED]> added the comment:
In Python 2.x range() always return a list.
In Python 3.x it will return an iterator.
Other functions will be changed to return an iterator too (see
http://www.python.org/dev/peps/pep-3100/#built-in-namespace).
--
nosy: +ezio.melotti
New submission from Diego <[EMAIL PROTECTED]>:
Hi.
I am a debian lenny user so i am still using python 2.5 so i dont know
how is this "bug" working on newer pythons. Please close it if you find
that it doesnt exists.
It may not be a bug but.
I have maked an script to optimice minterms sums (
