[Python-3000] iostack and Oh Oh

[Guido van Rossum]

On 12/1/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 11:52 AM 12/1/2006 -0800, Bill Janssen wrote:
> >Paul Moore writes:
> > > There is no expectation that all/most (or even
> > > many!) libraries would be based on ABCs. Duck typing would remain the
> > > norm. Although I'm not clear what the value of all this is, if the
> > > resulting ABCs *don't* get used in real code.
> >
> >I'm not sure what it means to base a library on ABCs.  You base types
> >on ABCs.
> >
> >But I'd hope that more library implementors would shift to documenting
> >required interfaces for parameters where appropriate, rather than the
> >current practice of either (1) not specifying anything, and forcing a
> >caller to read the code, or (2) spotty and incomplete documentation of
> >required methods, forcing smart callers to read the code.  And lots of
> >library implementors don't know what methods are required if you need
> >a value to support the "[k]" operation.  I would hope that eventually,
> >for most widely used library packages, duck typing would *not* be the
> >norm, because I think it's a source of both fragility and FUD in the
> >Python world.
>
> I would actually hope that library implementors would shift to using
> generic functions, since then they can just document what the function(s)
> are supposed to do, and people can just add methods to those functions for
> any object types they like, without needing to subclass anything, or have
> to deal with "interfaces" at all.

I'm not sure what you mean this. Are you proposing that a library
function that might take a mapping would be rewritten as a generic
library function with one implementation that takes a mapping? Or are
you proposing that the library function, instead of documenting that
it takes a mapping, documents which generic functions should be
applied to it?

Both sound like rather a big stretch from current practice.

> In other words, I just want to use my object with some operations that a
> library provides (or requires).  An "interface" is excise: something I have
> to mess with that doesn't directly relate to my goals for using the library.

I don't understand the sentence "An "interface" is excise". What does
excise mean in this context?

Regardless, I find it quite a big change from various ways of saying
"this object must have these methods (including perhaps some for which
special syntax exists, like __getattr__)" to saying "this object must
be supported by these generic functions". A method is just an
identifier in the object's attribute namespace. A generic function is
an object that may hve to be imported from elsewhere. This may make
sense in CLOS (if I understand the summary Bill gave me over lunch
Monday correctly) but is quite different from current practice in
Python.

> Generic functions are type-safe duck typing because ducklib.quack(ob)
> doesn't rely on ob having a 'quack()' method that means what you think it
> means.  This solves the problem simply and directly, without introducing
> interfaces and ABCs and whatnot.  Either the operation is defined for the
> type or it isn't.

I object to the suggestion that seems to be implied here that in the
future we'll all be writing ducklib.quack(ob) instead of the much
simpler ob.quack(). I really like that when I have an object in my
hands, I don't need to import anything else in order to manipulate it,
as long as the manipulation can be done through methods. I also don't
think that the homonym problem that you (and CLOS) are trying to solve
here is all that important in practice.

For the one homonym that is relevant in practice (__getitem__
ipmlemented by sequences and mappings alike, but with very different
invariants) I think I prefer Bill's ABC solution or an
interfaces-based solution over a GF-based solution, because the ABC
and the interface address the issue that there are invariants *across*
operations. (E.g. x in d equals x in d.keys(), len(d) == len(d.keys(),
d.items() == zip(d.keys(), d.values(), and and many more.)

So knowing that something is an instance of a Mapping ABC or interface
vs. a Sequence ditto conveys more information than knowing that it
implements __getitem__(). You could probably address this somewhat by
having two different oeprations, Mapping.__getitem__ and
Sequence.__getitem__, but that doesn't change the fact that the normal
spelling is x[y] in both cases, and it doesn't do much about the
relationships between different operations either.

(Did you see the example I posted about a week ago sketching an ABC or
interface hierarchy for sets? That strongly exemplified IMO the need
to be able to talk about a group of operations together with some
invariants, rather than just a bunch of operations.)

> At most, an interface need only specify what operations must be defined for
> a type, in order to allow it to be used for a different operation.

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