[Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

[Guido van Rossum]

On Sat, May 31, 2008 at 6:41 PM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Guido van Rossum" <guido at python.org>
>> 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.

I'd rather require that people rewrite their code to benefit from some
new piece of functionality than foisting it upon them regardless,
breaking some perfectly fine working in the process. This is how we've
always done it.

>> 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.

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.

> -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).

Fine, it was just an idle thought.

> 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. Where did you see __long__? That seems
a mistake (at least in 3.0).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)