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" <[EMAIL PROTECTED]> 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 > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
