From: "Guido van Rossum" <guido@python.org>
> > If we don't have the separate interface concept, the language just
> > isn't as expressive. We would have to establish a convention to
> > sacrifice one of -- a) being able to inherit from a class just for
> > implementation purposes or b) being able to reason about interfaces
> > using isinstance(). a) is error prone, because the language
> > wouldn't prevent anyone from making the mistake. b) is unfortunate,
> > because we'd have interfaces but no formal way to reason about them.
>
> So the point is that it's possible to have a class D that picks up
> interface I somewhere in its inheritance chain, by inheriting from a
> class C that implements I, where D doesn't actually satisfy the
> invariants of I (or of C, probably).
<snip>
> def foo(a: classA, b: classB):
> ...body...
>
> It would be convenient if this could be *defined* as
>
> assert isinstance(a, classA) and isinstance(b, classB)
>
> so that programs that have a simple class hierarchy can use their
> classes directly as argument types, without having to go through the
> trouble of declaring a parallel set of interfaces.
>
> I also think that it should be possible to come up with a set of
> standard "abstract" classes representing concepts like number,
> sequence, etc., in which the standard built-in types are nicely
> embedded.
Ah, but not all numbers are created equal! Can I write:
x << 1
? Not if x is a float. Somebody will eventually want to categorize numeric
types more-finely, e.g. Monoid, Euclidean Ring, ...
It sounds to my C++ ear like you're trying to make this analogous to
runtime polymorphism in C++. I think Python's polymorphism is a lot closer
to what we do at compile-time in C++, and it should stay that way: no
inheritance relationship needed... at least, not on the surface. Here's
why: people inevitably discover new type categories in the objects and
types they're already using. In C++ this happened when Stepanov et al
discovered that built-in pointers matched his mental model of random-access
iterators. A similar thing will happen in Python when you make all numbers
inherit from Number but someone wants to impose the real mathematical
categories (or heck: Integer vs. Fractional) on them.
What Stepanov's crew did did was to invent iterator traits, which decouple
the type's category from the type itself. Each category is represented by a
class, and those classes do have an inherticance relationship (i.e. every
random_access_iterator IS-A bidirectional_iterator). Actually, I have no
problem with collecting type category info from an object's MRO: as Guido
implies, that will often be the simplest way to do it. However, I think
there ought to be a parallel mechanism which allows additional
categorization non-intrusively, and it was my understanding that the PEP
Alex has been promoting does that.
-Dave
-----------------------------------------------------------
David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4