RetroSearch Browse

Thu Apr 27 12:14:26 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/064477.html

The real misunderstanding lies somewhere else. I thought that the
bitarray's instance would have more control over the long type's
instance, like with the mutable types. I thought that the long type's
superclass would provide methods similar to __setitem__ that would
allow the bitarray instance to even *refresh* (or substitute) the long
instance in place. The result would be a freshly created long instance
substituting the old one. But the immuntable types do not offer such a
feature because one cannot substitute the long instance without
breaking the bitarray instance too.

On Thu, 27 Apr 2006 07:20:47 +0200
"Martin v. Löwis" <martin at v.loewis.de> wrote:

> Dennis Heuer wrote:
> > The reason why I'd like to use the long type as the base of my bitarray
> > type is that the long type is already implemented as an array and
> > working efficiently with large amounts of bytes.
> 
> This is wrong; you are mixing up the "is-a" and "has-a" relationships.
> 
> While it might be useful to have long as the *representation* of a
> bitarray, it's not the case that a bitarray *is* a long. A bitarray
> is a sequence type and should implement all aspects of the sequence
> protocol; long is a numeric type and should implement numeric
> operations. While the operators for these somewhat overlap (for + and
> *), the semantics of the operators never overlaps. So long and
> bitarray are completely distinct types, not subtypes of each other.
> 
> IOW, you should do
> 
> class bitarray:
>   def __init__(self):
>     self.value = 0L
>   ...
> 
> Regards,
> Martin
> 
> 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/064477.html below:

[Python-Dev] inheriting basic types more efficiently