adalke at mindspring.com
Fri Jun 13 18:27:44 CEST 2003
> But wouldn't a type hierarchy be very useful for other types as
> well? For example, checking whether something is a number, currently
> needs isinstance(o, int) or isinstance(o, long), or float... although
> ints and longs are going to be the same. Would it be wise to let those
> have common base types?
I haven't needed that discrimination ... at least not that I can remember.
I have done some type-based dispatching, which was either very
specific (as for serialization of different data types) or special cased
one type, as in
if isinstance(file, string):
file = open(file)
The basestring type is useful because I want to handle byte strings and
unicode strings equivalently in many cases. But numbers as you mention?
> For example:
Suppose I have this:
def __getitem__(self, i):
if isinstance(i, int):
def __setitem((self, k, v):
self._headers_dict[k] = v
This is a specialized dict-like / list-like with mixed mutability.
(dict is more mutable, but list isn't immutable because elements
can be changed from underneath it.)
So this wouldn't be one of your types, but could be used by
code which overly asserts type checking. Which would be sad.
Except *possibly* for the existance of a "number" type, I don't
think this suggestion gives any useful power or flexibility to
Python, while encouraging ex-statically-typed-language programmers
to do unneeded and detrimental type checks.
dalke at dalkescientific.com
More information about the Python-list