[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> The problem I have sometimes in making my proposals clear to you is that,
> at the level of abstraction I think on, there are often multiple ways to
> carry out a useful/usable implementation, but you seem to want to
> understand one *particular* implementation, even though I'm trying to
> propose an approach to the solution, rather than a particular solution.

Oh, it would all be so much easier if we could all be in the same room
for a day...

The problem often seems to be that I don't have the imagination to
come up with a suitable implementation for the abstraction you are
describing, and at that point it's no longer an abstraction but an
arbitrary string of words to me. Those words may brim over with
meaning, but there are so many choices that it's hard to guess which
one is meant.

[[As an analogy, someone with a lot of HCI experience once pointed out
to me that when you show a code fragment to someone who isn't used to
programming, they tend to only see the words and lose the punctuation,
so for example they would see "self.__getattr__(x)+y" as "self getattr
x y" which loses a lot of meaning. Maybe I have the same problem with
some of your examples.]]

I guess an abstraction ideally needs to be described by formal
semantics, not by a hypothetical usage example. Since formal semantics
are often hard to come by, I'll settle for an implementation sketch.

For example, I really couldn't fathom what you meant for
addmethod(iter, ...) to do. It suddenly became completely clear once
you said "addmethod(x, ...) calls x.__addmethod__(...)".

> However, when I present you with a particular implementation, you then pick
> holes in the implementation itself, or the tradeoffs made to render the
> example simple.

That's unfortunate but can't always be avoided. I'm thinking that I
criticize the implementation in order to understand the abstraction
better. Since the implementation is often the only clue I have for
understanding the abstraction, if the implementation oversimplifies
things or has an obvious hole in it this distracts from the
understanding.

> If I knew what tradeoffs you would prefer ahead of time,
> then I could make my examples match the desired tradeoffs, but in the
> absence of that information I can only fall back to describing a general
> concept.

That's why I wish we had more direct face-to-face interaction.

> So we tend to go back and forth between abstractions rejected for
> lack of specificity, and specific things rejected for their particular
> nature.  :)  Perhaps I should try giving implementations explicitly
> labelled as prototypes and stating that there are other ways to do the same
> thing?

I don't know. In general, I find implementations that draw too
strongly on PEAK or RuleDispatch distracting because I'm not familiar
with their semantics or terminology and I'm in the "self getattr x y"
situation again.

At this point I think I understand the defop proposal and I understand
addmethod. But I think I could use some help with hasmethod. Suppose I
wanted to write the sendmail example using hasmethod. (I know it can
be written differently, but other examples may need hasmethod, and I'm
familiar with the sendmail example.) Could you should (a) what the
example would look like and (b) what would / could go on behind the
scenes to make it work? Bonus points for an attempt to show that it
can be implemented efficiently.

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