[Raymond]
I propose the following empty abstract classes: String, Datetime, Deque,
and Socket.
[GvR]
Sounds like a mini-PEP is in place. It should focus on the code to
actually define these and the intended ways to use them.
Okay, will run a Google code search to see if real code exists that
runs isinstance tests on the concrete types. Since the new classes
are very lightweight (completely empty), these probably only need
minimal justification.
The case for String has already been made. And the concept of a
Socket is already fully abstract. Not sure I really care about Deque.
The Datetime.class is tricky. The existence of many implementations
of date/time routines indicates that there is a need; however, they
don't share the API so they likely won't fit under a common umbrella.
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__.
I don't think Integer should be completely abstract (what good is an
int you can't add 1 to?) but I could be amenable to reducing the set
of required operations (which could then resurface as a separate ABC).
Please write another mini-PEP.
Okay. Will propose to remove the bit flipping methods and anything
else that doesn't seem essential to integeriness. Will take a look at
the integral types in numeric to see what that actually implement.
Where did you see __long__? That seems
a mistake (at least in 3.0).
It's the first listed abstract method in the Py2.6 code.
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
