[Python-3000] An introduction to ABC's

[Guido van Rossum]

On 4/17/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:47 AM 4/17/2007 +0100, Jan Grant wrote:
> >On Tue, 17 Apr 2007, Aurélien Campéas wrote:
> >
> > > But the unconclusiveness of all the discussions related to ABCs,
> > > interfaces and generic functions only show the immaturity of many on
> > > these topics. Including mine, of course, as in: I lack the experience
> > > required to back up all my claims about the generic function school of
> > > OO.  ... (although P. Eby did a great work on this front, he looks a bit
> > > lonely imho).
> >
> >FWIW Phillip's GFs look more and more like being the pythonic way to do
> >things. ABCs and interfaces work in a java world, where arguments to a
> >method arrive with a "preferred" type (ie, the type in the parameter
> >declaraion) and that type is used to interpret method calls when it
> >comes to method overloading. Hence Phillip's comment that interfaces are
> >"receiver-oriented".
>
> Yes...  and in *Java*, it tends to work out that way because a lot of
> factors conspire to make it work, like the fact that mere method names
> aren't enough to make an object acceptable, combined with overloading, lack
> of really useful generic types, etc.
>
>
> >We don't have that in python, which makes me question the utility of
> >creating a complex ABC universe prior to having a mechanism for method
> >dispatch.
> >
> >Of course, GF implementations _do_ exist which would give the ABCs some
> >utility. It's just a shame that there doesn't appear to be one that's
> >going to be the default way to do it in py3k.
>
> FYI, there's actually one tucked away in the pkgutil module since Python
> 2.5... single dispatch only, but it was the easiest way to support asking
> future PEP 302 importers what modules are in a package.  It's more
> primitive than the "simplegeneric" package on the Cheeseshop, but would
> certainly be functional enough to work with ABC's, if it were documented
> (at the moment it's technically an implementation detail of pkgutil.
>
> However, if there's interest, I'd be willing to create a *small* (i.e.
> about 1000 lines, give or take a few hundred) Py3K/2.6
> multi-dispatch/interface/adapters module, written such that it would be
> extensible for third-party dispatch and interface systems.  I'm not sure I
> could deliver a complete PEP before the deadline, however, and my
> impression is that Guido feels (or at least felt) that such a thing would
> be premature.  If that has changed, however, I'm willing to write a PEP and
> take a stab at getting a draft in this week.
>
> Anyway, if we do that, we would then have interfaces, adapters, generic
> functions, *and* ABCs in Py3K, so everybody should be happy...  except for
> those who want only one Obvious Way, of course.  :)

I'd like to see that PEP and that implementation.  I am planning to
make time to write my own PEP promoting ABCs. I think it would be
great if your code and mine could coexist and cooperate instead of
competing -- it's much easier to accept two PEPs than to have to
choose between two competing proposals. I don't take the TOOWTDI
concern too seriously; surely while there will be some overlap, for
many use cases it will be obvious which approach to take, and covering
more use cases means fewer times where applications or frameworks will
feel the need to roll their own.

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