range() is not the best way to check range?

[Summercoolness]

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, 30000):
if i in range (0, 10000):
a += 1
if not i % 1000: print i

print a, " ", round(time.time () - startTime, 1), "seconds"
---------------------------------
the last line of output is
---------------------------------

10001.0 22.8 seconds

so if i change the line

if i in range (0, 10000):

to

if i >= 0 and i < 10000:

the the last line is

10001.0 0.2 seconds

so approximately, the program ran 100 times faster!

or is there an alternative use of range() or something similar that can
be as fast?

[Antoon Pardon]

On 2006-07-20, Paul Boddie <pa**@boddie.or g.ukwrote:

Alex Martelli wrote:

>Paul Boddie <pa**@boddie.or g.ukwrote:

>
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 could provide a __contains__ method which could answer the
question of what the range contains based on the semantics guaranteed
by a range (in contrast to a normal list).

You'd also have to override just about every mutating method to switch
back to a "normal" __contains__ (or change self's type on the fly) -- a
pretty heavy price to pay.

A subclass of list is probably a bad idea in hindsight, due to various
probable requirements of it actually needing to be a list with all its
contents, whereas we wanted to avoid having anything like a list around
until the contents of this "lazy list" were required by the program. If
we really wanted to subclass something, we could consider subclassing
the slice class/type, but that isn't subclassable in today's Python for
some reason, and it doesn't really provide anything substantial,
anyway. However, Python being the language it is, an appropriately
behaving class is quite easily written from scratch.

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 python barfs on it when I want to use it as a
slice.

>>class sl(object):

.... def __init__(self, start = None, stop = None, step = None):
.... self.start = start
.... self.stop = stop
.... self.step = step
....

>>lst = range(20)
s1 = slice(3,13)
s2 = sl(3,13)
s1.start

3

>>s2.start

3

>>s1.stop

13

>>s2.stop

13

>>s1.step
s2.step
lst[s1]

[3, 4, 5, 6, 7, 8, 9, 10, 11, 12]

>>lst[s2]

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list indices must be integers

>>>

--
Antoon Pardon

[Paul Boddie]

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 python barfs on it when I want to use it as a
slice.

[s2 has start, stop, step...]

>lst[s2]

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list indices must be integers

In fact, the duck typing seems only to really work outside the
interpreter and the various accompanying built-in classes. Consider a
class similar to the one you defined with the name myslice (for
clarity) and with the apparently necessary indices method; consider it
used as follows:

>>range(0, 10)[myslice(1, 5, 2)]

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list indices must be integers

Here, we start to believe that only traditional index or slice notation
will work. However, we did come across the built-in slice class before;
consider this:

>>range(0, 10)[slice(1, 5, 2)]

[1, 3]

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 specific
set of types (presumably discoverable by looking at list_subscript in
listobject.c) rather than some objects conforming to some interface or
protocol, and perhaps it is implemented this way for performance
reasons.

In any case, in the core of Python some types/classes are more equal
than others, and for whatever reason the duck typing breaks down - a
case of "malbik endar" [1] that you just have to be aware of, I
suppose.

Paul

[1] http://www.sciamanna.com/island/pop/...lbik_endar.htm

[Steve Holden]

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 specific
set of types (presumably discoverable by looking at list_subscript in
listobject.c) rather than some objects conforming to some interface or
protocol, and perhaps it is implemented this way for performance
reasons.

In any case, in the core of Python some types/classes are more equal
than others, and for whatever reason the duck typing breaks down - a
case of "malbik endar" [1] that you just have to be aware of, I
suppose.

>>class mySlice(types.S liceType):

... pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Error when calling the metaclass bases
type 'slice' is not an acceptable base type

>>>

Indeed.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Antoon Pardon]

On 2006-07-21, Paul Boddie <pa**@boddie.or g.ukwrote:

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 specific
set of types (presumably discoverable by looking at list_subscript in
listobject.c) rather than some objects conforming to some interface or
protocol, and perhaps it is implemented this way for performance
reasons.

In any case, in the core of Python some types/classes are more equal
than others, and for whatever reason the duck typing breaks down - a
case of "malbik endar" [1] that you just have to be aware of, I
suppose.

Is there any chance this will iever change?

Is there any chance the start:stop:step notation will ever
be considered an atom?

--
Antoon Pardon

[Paul Boddie]

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
range/xrange class, but passing objects of that class around should
prove satisfactory for the use of most programs. I personally doubt
that it is that much hard work, especially if you stick to a reasonable
selection of list capabilities, for example, rather than attempting to
emulate support for every dodgy trick available to the programmer in
the modern CPython arsenal.

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 python barfs on it when I want to use it as a
slice.

Yes, my post showed this and gave a reference to where in the CPython
source code the tests for specific types are performed.

Paul

[Antoon Pardon]

On 2006-07-23, Paul Boddie <pa**@boddie.or g.ukwrote:

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 could be very usefull for that.

To me it feel very natural that a slice would be iterable and
could be used in a form like:

for i in slice(10,20):

or if the slice notation would be usable

for i in (10:20):

And why not make a slice indexable too?
Whether slices really are the tool to use here or not
I don know for sure. But the problem is, that you
can't easily experiment with this idea because slices
are not subclassable.

It may be "hard work" writing all those methods in a totally new
range/xrange class, but passing objects of that class around should
prove satisfactory for the use of most programs.

But the parameters you will have to give such a class are the same
you have to pass to a slice. IMO that means that you should at least
consider giving slices this functionality. At least it should be
easy to convert from one to the other and back.

--
Antoon Pardon