[Python-Dev] type categories

[Martijn Faassen]

Oren Tirosh wrote:
> On Wed, Aug 14, 2002 at 09:38:18PM -0400, Andrew Koenig wrote:
> > >> Not really.  I can see how an interface can claim that a particular
> > >> method exists, but not how it can claim that the method implements a
> > >> function that is antisymmetric and transitive.
> > 
> > Guido> That's done in the docs, usually.  Zope even has the notion of a
> > Guido> "marker" interface -- an interface that says "this object has property
> > Guido> such-and-such" but which does not assert any methods or attributes.
> > 
> > So perhaps what I mean by a category is the set of all types that
> > implement a particular marker interface.
> 
> I propose that any method or attribute may serve as a marker. This makes it
> possible to use an existing practice as a marker so protocols can be
> defined retroactively for an existing code base. It's also possible, of 
> course, to add an attribute called 'has_property_such_and_such' to serve 
> as an explicit marker.

This is an interesting idea. I'd say you could plug such a 
thing into an interface system, by making 'interface.isImplementedBy()' 
calling some hooks that may dynamically claim an object implements
an interface, based on methods and attributes.

I'm not sure if it's a good idea, as if you're going to state this in
code anyway it seems to me it's clearer to actually explicitly use marker
interfaces instead of writing some code that guesses based on the presence
of particular attributes, but it's definitely an interesting idea.

[snip] 
> A new category may be defined as a union or intersection of two existing
> categories. This is done by ANDing or ORing the membership predicates of
> the two categories and reducing them back to canonical form.

This is similar to some ideas I came up with a couple of years ago on the
types-SIG, and Guido told me to talk about it at a conference over some beer,
instead. :)

http://mail.python.org/pipermail/types-sig/1999-December/000633.html

http://mail.python.org/pipermail/types-sig/2000-January/000923.html
(see bottom: Interfaces can be implied:)

and here's Guido's finding my idea too absurd:
http://mail.python.org/pipermail/types-sig/2000-January/000932.html

But they're still interesting ideas. :) You can basically deduce what
attributes (and methods) are on an interface by just giving a whole bunch 
of classes that you claim implement the interface, for instance.

Regards,

Martijn