does Python support some kind of "casting"

[Peter Hansen]

Rich Harkins wrote:
> 
> On Friday 15 March 2002 08:17 am, Peter Hansen wrote:
> > Get over it.  3600 elements is nothing, especially once you realize that
> > the strings themselves are not duplicated, just the references.
> >
> Isn't there some additional overhead (above copying the underlying C array
> for the list) in having to bump each refcount of every object contained?

Yeah, like a few tiny C instructions... don't get concerned over the
performance at that level when writing Python.  You are already writing
code between 10 and 100 times slower than equivalent C in most cases,
so a few extra microseconds doesn't amount to much. 

Then, too, there's how often the routine will execute.  A lot of 
people wondering how to optimize something when they haven't even
benchmarked it and found it lacking against some real need for speed
aren't even planning to run the code very often!  Sometimes these
are little one-shot utilities which you might run a few times a day,
and any savings will amount to less time over the lifetime of the
code than the extra time spent optimizing...

> This would appear on the surface to be not trivial when the number of
> referenced objects becomes large, 

It's still trivial, considering that it scales as O(n) so you won't
notice it whether it's 10 items or 10,000 items.  The overhead of 
Python in other respects is much more than the ref-counting.

> OTOH, I do wonder if some form of list-based buffer() would be useful in
> these cases, so that you can take a slice of a list, bump the list's refcount
> without bumping the referenced objects 

You could implement this with some kind of unmutable list object
if you wished.  If you guarantee you won't modify the list content,
you get this for free with the current implementation, just by binding
the object to another name...

-Peter