2008/4/30, Nick Coghlan <[EMAIL PROTECTED]>:
> In the bug tracker, Alexander mentioned the possibility of removing
> __length__ and __getitem__ support from range() objects in py3k, and
> implementing only __length_hint__ instead (leaving range() as a bare-bones
> iterable). I'm starting to like
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> In the slow example given, only one of the returned items needs to be a
>>> long
>>
>> This is Py3k. They are all longs.
>
> Not inside the object they aren't
Right, inside, they are longs - but the *returned items* are all longs.
> One way to opt
On Thu, May 1, 2008 at 10:41 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> One way to optimise this (since all we need to support here is counting
> rather than arbitrary arithmetic) would be for the longrange iterator to use
> some simple pure C fixed point arithmetic internally to keep track of
Martin v. Löwis wrote:
In the slow example given, only one of the returned items needs to be a
long
This is Py3k. They are all longs.
Not inside the object they aren't - I believe the optimised one uses C
longs internally, and converts to a Python long when it returns the
values, whereas 'l
> In the slow example given, only one of the returned items needs to be a
> long
This is Py3k. They are all longs.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http
Martin v. Löwis wrote:
These numbers aren't ridiculously large. I just tried
for i in range(2**31): pass
on my (32-bit) laptop: it took 736.8 seconds, or about 12 and a bit minutes.
(An aside: in contrast,
for i in range(2**31-1): pass
took only 131.1 seconds; looks like there's some potent
> These numbers aren't ridiculously large. I just tried
>
> for i in range(2**31): pass
>
> on my (32-bit) laptop: it took 736.8 seconds, or about 12 and a bit minutes.
> (An aside: in contrast,
>
> for i in range(2**31-1): pass
>
> took only 131.1 seconds; looks like there's some potential f
As I said before, apparently it is practical in the Java world.
On Wed, Apr 30, 2008 at 5:26 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Wed, Apr 30, 2008 at 7:16 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > But I didn't find a rationale. I'm sure it was PBP though.
> >
On Wed, Apr 30, 2008 at 7:16 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > But I didn't find a rationale. I'm sure it was PBP though.
> >
> > What's PBP? (A search only turns up a bicycle race. :))
>
> Practicality Beats Purity, from the zen of Python
It's practical to have a builti
On Wed, Apr 30, 2008 at 5:10 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Wed, Apr 30, 2008 at 6:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I've come across situations where len() raising an exception was more
> > inconvenient than returning a truncated value (e.g. when pri
On Wed, Apr 30, 2008 at 6:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've come across situations where len() raising an exception was more
> inconvenient than returning a truncated value (e.g. when printing).
In those cases, shouldn't you be explicit, catch the overflow
exception, and
On Wed, Apr 30, 2008 at 4:14 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >
> > On Wed, Apr 30, 2008 at 3:49 PM, Greg Ewing <[EMAIL PROTECTED]>
> wrote:
> >
> >
> >
> > > So that code will silently behave as though the rest of
> > > the sequence wasn't there some of the t
On Wed, Apr 30, 2008 at 4:11 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> In the bug tracker, Alexander mentioned the possibility of removing
> __length__ and __getitem__ support from range() objects in py3k, and
> implementing only __length_hint__ instead (leaving range() as a bare-bones
> itera
Guido van Rossum wrote:
On Wed, Apr 30, 2008 at 3:49 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
So that code will silently behave as though the rest of
the sequence wasn't there some of the time?
Only if it uses LBYL.
I don't understand that. Iteration isn't the only thing
one does with sequ
Greg Ewing wrote:
Guido van Rossum wrote:
I would like to see the following:
- sq_length should return maxsize if the actual value doesn't fit
So that code will silently behave as though the rest of
the sequence wasn't there some of the time?
Can you elaborate on the rationale for this? I'm
On Wed, Apr 30, 2008 at 3:49 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I would like to see the following:
> >
> > - sq_length should return maxsize if the actual value doesn't fit
> >
>
> So that code will silently behave as though the rest of
> the sequence wasn't
Guido van Rossum wrote:
I would like to see the following:
- sq_length should return maxsize if the actual value doesn't fit
So that code will silently behave as though the rest of
the sequence wasn't there some of the time?
Can you elaborate on the rationale for this? I'm having
trouble seei
I would like to see the following:
- sq_length should return maxsize if the actual value doesn't fit
- if __len__ is implemented in Python, it may return a value >
maxsize, but calling len() will call sq_length, and the sq_length
wrapper that calls __len__ must truncate the value to maxsize
- if
Dnia 29-04-2008, wto o godzinie 19:36 -0700, Guido van Rossum pisze:
> Let's also fix __len__() so that it returns sys.{maxint,maxsize} when
> the result doesn't fit in a Py_ssize_t.
Is this official? What should sq_length do when the real size doesn't
fit in a Py_ssize_t? It should be documented
On Wed, Apr 30, 2008 at 10:05 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> >
> > What would you say to an idea of exposing rangeiter in itertools - say
> > itertools.irange(..) function that returns an iterator?
>
> You're kidding right? If you *want* the iterator, what's wrong with
>
On Tue, Apr 29, 2008 at 8:22 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ..
> > There are good reasons for having range() return an Iterable and not
> > an Iterator;
>
> What would you say to an idea of
On Tue, Apr 29, 2008 at 8:22 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ..
> > There are good reasons for having range() return an Iterable and not
> > an Iterator;
>
> What would you say to an idea of
On Tue, Apr 29, 2008 at 7:53 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ..
> > There are good reasons for having range() return an Iterable and not
> > an Iterator; e.g.
> >
> > R = range(N)
> > for
Alexander Belopolsky wrote:
On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
R = range(N)
for i in R:
for j in R:
You realize that in the snippet above whatever cycles you save by
creating R once, you give away by creating iter(R) twice.
I'm not so su
On Tue, Apr 29, 2008 at 8:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Let's also fix __len__() so that it returns sys.{maxint,maxsize} when
> the result doesn't fit in a Py_ssize_t.
Why not leave sq_length as is, but have len() bypass it and call
.__len__() directly? C code is likely a
On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> There are good reasons for having range() return an Iterable and not
> an Iterator;
What would you say to an idea of exposing rangeiter in itertools - say
itertools.irange(..) function that returns an iterator?
__
Correction: My calculation below was only correct for N = 1 case. In
general, the two alternatives will create N+2 vs. N+1 auxiliary
objects.
On Tue, Apr 29, 2008 at 10:53 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]>
On Tue, Apr 29, 2008 at 5:18 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
..
> > Put another way: range(n) currently works, in Py3k, for n > sys.maxsize.
> > What's the rationale for breaking that?
>
> So we can support other sequence methods. (I think.)
>
This is not true. The missing sequ
On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> There are good reasons for having range() return an Iterable and not
> an Iterator; e.g.
>
> R = range(N)
> for i in R:
> for j in R:
>
You realize that in the snippet above whatever cycles you save b
I propose to remove the support for indexing; it is a carryover from
before Python 2.2 when there was no .next() method.
There are good reasons for having range() return an Iterable and not
an Iterator; e.g.
R = range(N)
for i in R:
for j in R:
so here I propose to keep the status quo
On Tue, Apr 29, 2008 at 7:48 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> Let's just stop the discussion here and kill all proposals to add
> indexing/slicing etc. Sorry, Alexander, but there just isn't anyone
> besides you in favor, and nobody has brought up a convincing use case.
>
Th
On Tue, Apr 29, 2008 at 2:18 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 4:09 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > Put another way: range(n) currently works, in Py3k, for n > sys.maxsize.
> > What's the rationale for breaking that?
>
> So we can suppo
2008/4/29, Benjamin Peterson <[EMAIL PROTECTED]>:
> On Tue, Apr 29, 2008 at 4:09 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > Put another way: range(n) currently works, in Py3k, for n > sys.maxsize.
> > What's the rationale for breaking that?
>
> So we can support other sequence methods. (
"Alexander Belopolsky" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Mon, Apr 28, 2008 at 7:18 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
| ..
| > The cost of the extra functionality: writing it, reviewing it, adding
| > unittests, documenting it, maintaining it, making
On Tue, Apr 29, 2008 at 4:09 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> Put another way: range(n) currently works, in Py3k, for n > sys.maxsize.
> What's the rationale for breaking that?
So we can support other sequence methods. (I think.)
Personally, I think that range should be just an ea
On Tue, Apr 29, 2008 at 4:30 PM, Alexander Belopolsky <
[EMAIL PROTECTED]> wrote:
> I would say that if it is possible that n exceeds a few hundred
> million, it is a good idea to pause and think whether you want to have
> this loop implemented in Python to begin with.
>
Maybe. But the answer is
On Tue, Apr 29, 2008 at 4:17 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
..
> I'd like to be able to write
>
> for i in range(n):
> ...
>
> without having to stop and worry about whether n is always going
> to be small enough to avoid an exception, and what to do if there's
> a possibility t
On Tue, Apr 29, 2008 at 10:30 AM, Alexander Belopolsky <
[EMAIL PROTECTED]> wrote:
> or sizable. I would say "range(n) is a memory efficient substitute
> for [0, 1, ... n-1]" is easier to fit into one's brain that the
> current hodgepodge of exceptions.
>
For what it's worth, I'm -1 on any chan
On Mon, Apr 28, 2008 at 7:18 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> The cost of the extra functionality: writing it, reviewing it, adding
> unittests, documenting it, maintaining it, making sure it works on
> 64-bit machines, having Python book authors discuss it; and in
> additio
On Mon, Apr 28, 2008 at 7:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> BTW, if you're looking for a term describing range() that's better
> than set or sequence, how about "series"? It's a mathematical word
> that matches pretty exactly.
No, mathematical series is the sum of a sequence:
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| BTW, if you're looking for a term describing range() that's better
| than set or sequence, how about "series"? It's a mathematical word
| that matches pretty exactly. (More accurately, I believe it's an
| algebraic s
BTW, if you're looking for a term describing range() that's better
than set or sequence, how about "series"? It's a mathematical word
that matches pretty exactly. (More accurately, I believe it's an
algebraic series.)
On Mon, Apr 28, 2008 at 4:18 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> O
On Sun, Apr 27, 2008 at 4:07 AM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Sat, Apr 26, 2008 at 2:49 PM, Facundo Batista
> <[EMAIL PROTECTED]> wrote:
>
>
> > Which should the range() definition be, in your words?
>
> In terms of ABCs, range(..) is a Sized Iterable in the current
> i
On Sun, Apr 27, 2008 at 10:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Alexander Belopolsky wrote:
..
> > I believe it would make sense to turn range(..) into a Sequence.
..
> I like this as a goal - I'll make sure to find the time to help review any
> patches aimed at achieving it (startin
Alexander Belopolsky wrote:
On Sat, Apr 26, 2008 at 2:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
Which should the range() definition be, in your words?
In terms of ABCs, range(..) is a Sized Iterable in the current
implementation. It is not a Sequence because it is not a Container
a
On Sat, Apr 26, 2008 at 2:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> Which should the range() definition be, in your words?
In terms of ABCs, range(..) is a Sized Iterable in the current
implementation. It is not a Sequence because it is not a Container
and does not support slicing.
Benjamin Peterson wrote:
On Sat, Apr 26, 2008 at 3:34 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
"Set" is definitely misleading -- it has no ordering.
True. I was trying to convey the unrepeated part of the set
definition. Is "an ordered set of integers" better?
What's wrong with 'sequence
>> lens are forced to be <= Py_ssize_t because that's the limit put on
>> sequence sizes.
>
> But this should be a secuence issue... or not? Why I'm limiting the
> general len()/__len__ infrastructure?
Because a C type is used to represent it, not a Python object. Any
C type (whichever you chos
On Sat, Apr 26, 2008 at 3:34 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> "Set" is definitely misleading -- it has no ordering.
True. I was trying to convey the unrepeated part of the set
definition. Is "an ordered set of integers" better?
--
Cheers,
Benjamin Peterson
Benjamin Peterson schrieb:
On Sat, Apr 26, 2008 at 1:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
Which should the range() definition be, in your words?
"A set of integers from start to stop skipping step."
[ ... ]
"Set" is definitely misleading -- it has no ordering.
Georg
--
Thus
On Sat, Apr 26, 2008 at 2:06 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
>
>
> > lens are forced to be <= Py_ssize_t because that's the limit put on
> > sequence sizes.
>
> But this should be a secuence issue... or not? Why I'm limiting th
2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
> lens are forced to be <= Py_ssize_t because that's the limit put on
> sequence sizes.
But this should be a secuence issue... or not? Why I'm limiting the
general len()/__len__ infrastructure?
Thanks!
--
.Facundo
Blog: http://www.taniqu
On Sat, Apr 26, 2008 at 1:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> Which should the range() definition be, in your words?
"A set of integers from start to stop skipping step."
[ ... ]
> At this moment I stopped writing this mail, and I went to code a
> Range() class to have the sem
2008/4/26 Alexander Belopolsky <[EMAIL PROTECTED]>:
> > What is range()?
> >
> > help(range) shows me that range "Returns an iterator that generates
> > the numbers in the range on demand."
>
> This is not correct in 3.x: range does not return an iterator. There is an
> iterator similar to r
Alexander Belopolsky wrote:
Facundo Batista gmail.com> writes:
Ahá! So, as ints are unbound in Python, I could easily do:
r = range(1,10)
The problem with supporting this is that len(r) will raise overflow error.
It would be nice to get rid of the limitation on len(), bu
Facundo Batista gmail.com> writes:
>
> 2008/4/26, Benjamin Peterson gmail.com>:
..
> What is range()?
>
> help(range) shows me that range "Returns an iterator that generates
> the numbers in the range on demand."
>
This is not correct in 3.x: range does not return an iterator. There is an
i
2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
> First of all, should the length of range be completely constricted by
> Py_ssize_t? (issue 2690) Since indexing already is constrained by
> this, it would make sense to make the whole object live under that
What is range()?
help(range) shows
57 matches
Mail list logo
