From: "Guido van Rossum" <[EMAIL PROTECTED]>
I'm willing to meet you halfway. I really don't want isinstance(x,
str) to return True for something that doesn't inherit from the
concrete str type; this is bound to lead to too much confusion and
breakage.
Probably true. It was an attractive idea though. Unless all client
code converts all its isinstance() tests from concrete to abstract,
life is going to be tough for people writing look-alike classes
which will have limited applicability.
But I'm fine with a String ABC (or any other ABC, e.g.
Atomic?) that doesn't define any methods but can be used for type
testing. How about that?
That's progress! It makes abstract substitution possible while
still saving us a lot of code and avoiding over-specification.
I propose the following empty abstract classes:
String, Datetime, Deque, and Socket.
-1 on Atomic though. Earlier in the thread it was made clear that
that atomicity is not an intrinsic property of a type; instead it varies
across applications (when flattening email folders, a multi-part mime
message is atomic, but when flattening individual messages, a
multi-part mime message is just another nested container, part
of the tree, not one of the leaves).
Are you open to considering numbers.Integral to be one of the
new empty abstract classes? That would make it much easier
for objects wanting to pass themselves as integers. As it stands
now, an aspiring Integral class is required to implement a number
of arcana including: __rxor__, __rrshift__, __pow__, __invert__,
__index__, and __long__.
Raymond
_______________________________________________
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
