On 2006-07-23, Paul Boddie [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
Except that if you write your own class from scratch, you can't use
it as a slice.
Correct, but we were actually discussing subclassing built-in classes
for use as a replacement for range/xrange. :-)
I think a slice
On 2006-07-21, Paul Boddie [EMAIL PROTECTED] wrote:
Regardless of whether myslice inherits from object or not, there's no
persuading the interpreter that it is a genuine slice, and remember
that we can't subclass slice (for some reason unknown). So, it would
appear that the interpreter really
Antoon Pardon wrote:
Except that if you write your own class from scratch, you can't use
it as a slice.
Correct, but we were actually discussing subclassing built-in classes
for use as a replacement for range/xrange. :-)
It may be hard work writing all those methods in a totally new
On 2006-07-20, Paul Boddie [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
Paul Boddie [EMAIL PROTECTED] wrote:
Well, range is a function in the current implementation, although its
usage is similar to that one would get if it were a class, particularly
a subclass of list or one providing
Antoon Pardon wrote:
[Subclasses of list or slice for ranges]
Except that if you write your own class from scratch, you can't use
it as a slice. For a language that is supposed to be about duck typing
I find it strange that if I make my own class with a start, stop and
step attribute, that
Paul Boddie wrote:
[...]
Regardless of whether myslice inherits from object or not, there's no
persuading the interpreter that it is a genuine slice, and remember
that we can't subclass slice (for some reason unknown). So, it would
appear that the interpreter really wants instances from some
Paul Boddie [EMAIL PROTECTED] wrote:
John Machin wrote:
range() and xrange() are functions. You are suggesting that 2
*functions* should acquire a __contains__ method each? I trust not.
Well, range is a function in the current implementation, although its
usage is similar to that one
Alex Martelli wrote:
Paul Boddie [EMAIL PROTECTED] wrote:
Well, range is a function in the current implementation, although its
usage is similar to that one would get if it were a class, particularly
a subclass of list or one providing a list-style interface. With such a
class, you
Paul Boddie [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
Paul Boddie [EMAIL PROTECTED] wrote:
Well, range is a function in the current implementation, although its
usage is similar to that one would get if it were a class, particularly
a subclass of list or one providing a
Paul Boddie wrote:
John Machin wrote:
On 19/07/2006 1:05 AM, Dan Bishop wrote:
xrange already has __contains__.
As pointed out previously, xrange is a function and one would not expect
it to have a __contains__ method.
Well, you pointed out that range is a function, but xrange
In [EMAIL PROTECTED], tac-tics
wrote:
Grant Edwards wrote:
for pete's sake use the comparison operator like god intended.
if 0 = i = 1:
I'm assuming you used Python's compound comparison as opposed to the
C-style of and'ing two comparisons together to emphasize the fact it is
Grant Edwards [EMAIL PROTECTED] wrote:
Creating and then searching a 10,000 element list to see if a
number is between two other numbers is insane.
Using xrange as somebody else suggested is also insane.
Aye to both
If you want to know if a number is between two other numders,
for
John Machin wrote:
On 18/07/2006 12:41 PM, [EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
[...]
Some things to try:
1a. Read what the manual has to say about the range() function ... what
does it produce?
Indeed. Still, the addition of a __contains__ method to range
[EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
if i in range (0, 1):
RTFM on range()
You're completely mis-using it here, using it with an if ... in ...
test. The purpose of range() in Python is as loop control, not
comparisons! It's not a SQL BETWEEN statement.
Grant Edwards wrote:
Using xrange as somebody else suggested is also insane.
Sorry about that, I somehow got the misguided notion that xrange defines
its own __contains__, so that it would be about the same speed as using
comparison operators directly. I figured the OP might have a better
On 18/07/2006 7:22 PM, Paul Boddie wrote:
John Machin wrote:
On 18/07/2006 12:41 PM, [EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
[...]
Some things to try:
1a. Read what the manual has to say about the range() function ... what
does it produce?
Indeed. Still,
John Machin wrote:
range() and xrange() are functions. You are suggesting that 2
*functions* should acquire a __contains__ method each? I trust not.
Well, range is a function in the current implementation, although its
usage is similar to that one would get if it were a class, particularly
a
Andy Dingley wrote:
The purpose of range() in Python is as loop control,
No, the purpose of range() is to create a list, as the docs state.
http://docs.python.org/lib/built-in-funcs.html
range(...) - This is a versatile function to create lists containing
arithmetic progressions.
Stefan
--
Paul Boddie wrote:
Yes, he wants range to return an iterator, just like xrange more or
less does now. Given that xrange objects support __getitem__, unlike a
lot of other iterators (and, of course, generators), adding
__contains__ wouldn't be much of a hardship. Certainly, compared to
other
On 2006-07-18, tac-tics [EMAIL PROTECTED] wrote:
Grant Edwards wrote:
for pete's sake use the comparison operator like god intended.
if 0 = i = 1:
I'm assuming you used Python's compound comparison as opposed to the
C-style of and'ing two comparisons together to emphasize the fact
On 2006-07-18, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], tac-tics
wrote:
Grant Edwards wrote:
for pete's sake use the comparison operator like god intended.
if 0 = i = 1:
I'm assuming you used Python's compound comparison as opposed to the
C-style
On 2006-07-18, Paul Boddie [EMAIL PROTECTED] wrote:
John Machin wrote:
range() and xrange() are functions. You are suggesting that 2
*functions* should acquire a __contains__ method each? I trust
not.
Well, range is a function in the current implementation,
although its usage is similar to
Grant Edwards wrote:
On 2006-07-18, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], tac-tics
wrote:
Grant Edwards wrote:
for pete's sake use the comparison operator like god intended.
if 0 = i = 1:
I'm assuming you used Python's compound comparison as
Dan Bishop wrote:
[EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
...
if i in range (0, 1):
This creates a 10,000-element list and sequentially searches it. Of
course that's gonna be slow.
And you're doing it 3 times.
--
Nick Craig-Wood wrote:
Sets are pretty fast too, and have the advantage of flexibility in
that you can put any numbers in you like
I know this is self-evident to most of the people reading this, but I
thought it worth pointing out that this is a great way to test
membership in range(lo, hi,
Simon Forman wrote:
Nick Craig-Wood wrote:
Sets are pretty fast too, and have the advantage of flexibility in
that you can put any numbers in you like
I know this is self-evident to most of the people reading this, but I
thought it worth pointing out that this is a great way to test
Simon Forman wrote:
Nick Craig-Wood wrote:
Sets are pretty fast too, and have the advantage of flexibility in
that you can put any numbers in you like
I know this is self-evident to most of the people reading this, but I
thought it worth pointing out that this is a great way to test
Diez B. Roggisch wrote:
Simon Forman wrote:
Nick Craig-Wood wrote:
Sets are pretty fast too, and have the advantage of flexibility in
that you can put any numbers in you like
I know this is self-evident to most of the people reading this, but I
thought it worth pointing out that
Grant Edwards wrote:
It's unclear what you're referring to as the range.
The notion of something describing a range of values which can be
expanded to a list or, of relevance here, whose boundaries can be
tested efficiently.
Perhaps you're thinking of a slice? Somethign like
if
On 2006-07-18, Steve Holden [EMAIL PROTECTED] wrote:
That said, for pete's sake is probably a just an cleaned up
version of for god's sake, so I probably did call pete god.
No, actually you called god pete ;-)
Well that's certainly wrong, because we all know god's name is
Howard.
Our
On 2006-07-18, Paul Boddie [EMAIL PROTECTED] wrote:
It's unclear what you're referring to as the range.
The notion of something describing a range of values which can be
expanded to a list or, of relevance here, whose boundaries can be
tested efficiently.
Perhaps you're thinking of a
Dan Bishop:
xrange already has __contains__. The problem is, it's implemented by a
highly-inefficient sequential search. Why not modify it to merely
check the bounds and (value - start) % step == 0?
I think this is a nice idea.
Bye,
bearophile
--
K.S.Sreeram wrote:
Simon Forman wrote:
Nick Craig-Wood wrote:
Sets are pretty fast too, and have the advantage of flexibility in
that you can put any numbers in you like
I know this is self-evident to most of the people reading this, but I
thought it worth pointing out that this is
[EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
if i in range (0, 1):
My original use was like this:
if i in range (iStart, iEnd):
listData.append(a)
in which iStart is 1000 and iEnd is 1008
so in that case, the program ran fine...
but later on, i
Simon Forman wrote:
To me, and perhaps others, T =
set(xrange(0, 1, 23)) and n in T are somewhat easier to read
and write than not n % 23 and 0 = n 1, YMMV.
Eh? How is the first easier to read than the second?? You have a nested
function call in the first!
Regardless, testing if a
On 19/07/2006 1:05 AM, Dan Bishop wrote:
Paul Boddie wrote:
Yes, he wants range to return an iterator, just like xrange more or
less does now. Given that xrange objects support __getitem__, unlike a
lot of other iterators (and, of course, generators), adding
__contains__ wouldn't be much of
John Machin wrote:
On 19/07/2006 1:05 AM, Dan Bishop wrote:
xrange already has __contains__.
As pointed out previously, xrange is a function and one would not expect
it to have a __contains__ method.
Well, you pointed out that range is a function, but xrange seems to be
a type...
xrange
tac-tics wrote:
Simon Forman wrote:
To me, and perhaps others, T =
set(xrange(0, 1, 23)) and n in T are somewhat easier to read
and write than not n % 23 and 0 = n 1, YMMV.
Eh? How is the first easier to read than the second?? You have a nested
function call in the first!
I
it seems that range() can be really slow:
the following program will run, and the last line shows how long it ran
for:
import time
startTime = time.time()
a = 1.0
for i in range(0, 3):
if i in range (0, 1):
a += 1
if not i % 1000: print i
print a,,
[EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
...
if i in range (0, 1):
This creates a 10,000-element list and sequentially searches it. Of
course that's gonna be slow.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
or is there an alternative use of range() or something similar that can
be as fast?
You could use xrange:
[EMAIL PROTECTED]:~$ python -m timeit -n1 1 in range(1)
1 loops, best of 3: 260 usec per loop
[EMAIL PROTECTED]:~$ python -m timeit -n1 1 in
Leif K-Brooks wrote:
[EMAIL PROTECTED] wrote:
or is there an alternative use of range() or something similar that can
be as fast?
You could use xrange:
[EMAIL PROTECTED]:~$ python -m timeit -n1 1 in range(1)
1 loops, best of 3: 260 usec per loop
[EMAIL PROTECTED]:~$ python
On 18/07/2006 12:41 PM, [EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
the following program will run, and the last line shows how long it ran
for:
import time
startTime = time.time()
a = 1.0
for i in range(0, 3):
if i in range (0, 1):
a +=
[EMAIL PROTECTED] wrote:
so if i change the line
if i in range (0, 1):
to
if i = 0 and i 1:
[snip;]
is there an alternative use of range() or something similar that can
be as fast?
you've found that alternative yourself! just use the comparison operators...
in fact, you
On 2006-07-18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
it seems that range() can be really slow:
the following program will run, and the last line shows how long it ran
for:
import time
startTime = time.time()
a = 1.0
for i in range(0, 3):
if i in range (0, 1):
Grant Edwards wrote:
for pete's sake use the comparison operator like god intended.
if 0 = i = 1:
I'm assuming you used Python's compound comparison as opposed to the
C-style of and'ing two comparisons together to emphasize the fact it is
god's chosen way of doing this ;-)
--
46 matches
Mail list logo
