[Python-3000] ABC's, Roles, etc

Jeff Shell eucci.group at gmail.com
Sat May 12 19:58:10 CEST 2007


On 5/10/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:06 AM 5/10/2007 -0400, Benji York wrote:
> >I would let Jim speak for himself too, but I prefer to put words in his
> >mouth. ;)  While zope.interface has anemic facilities for "verifying"
> >interfaces, few people use them, and even then rarely outside of very
> >simple "does this object look right" when testing.  It may have been
> >believed verification would be a great thing, but it's all but
> >deprecated at this point.
>
> Okay, but that's quite the opposite of what I understand Jeff to be
> saying in this thread, which is that not only is LBYL good, but that
> he does it all the time.

Actually, I don't know what LBYL and EFTP (or whatever that other one
is) mean in this context. This is the first time I've heard, or at
least paid attention to, those acronyms. In this context anyways.

If you could explain what this really means, and KTATAM (Keep The
Acronyms To A Minimum), I would appreciate it. I recognize the
arguments I've made seem to go behind LBYL, but that was mostly chosen
because that's what you said zope.interface did or was. And
gul-darnit, I like zope.interface.

> >My main intent in piping up was
> >dispelling the LBYL dispersions about zope.interface. ;)
>
> Well, "back in the day", before PyProtocols was written, I discovered
> PEP 246 adaptation and began trying to convince Jim Fulton that
> adaptation beat the pants off of using if-then's to do "implements"
> testing.  His argument then, IIRC, was that interface verification
> was more important.  I then went off and wrote PyProtocols in large
> part (specifically the large documentation part!) to show him what
> could be done using adaptation as a core concept.

I think it's beneficial to have both. But I agree, it's usually better
to program against adaptation. It provides more flexibility. I think
the 'hasattr()' syndrome still hangs over many of us, however. We're
used to looking at the piece of the duck we're interested in more than
trying to see if we can put something into a duck suit (or better yet
- Duck Soup!)

But the 'provides / provided by' piece is still important to me.
Adaptation isn't *always* needed or useful.

I like that the interface hierarchy is different than an
implementation hierarchy. I like that it's easier to test for
interface provision than it is to use isinstance() -
`IFoo.providedBy(obj)` often works regardless of whether 'obj' is a
proxy or wrapper, and without tampering with `isinstance()`. I know
that there's been talk of having ``__isinstance()__`` and
``__issubclass()__``, which could be used to take care of the
proxy/wrapper problem. But I haven't formed an opinion about how I
feel about that.

I like the Roles/Traits side of zope.interface because I can declare
that information about third party products. For example, I was able
to add some 'implements' directives to a SQLAlchemy 'InstrumentedList'
class - basically I said that it supported the common `ISequence`
interface. Which I recognize that in this particular scenario, if that
role/trait or abstract base class was built in, than I wouldn't have
had to do that (since it is based on a common Python type spec). Still
though - it doesn't matter whether `InstrumentedList` derives from
`list` or `UserList` or implements the entire sequence API directly.
The Trait could be assigned independent of implementation, and could
be done in another product without affecting any internals of
SQLAlchemy: I didn't have to make a subclass that SQLAlchemy wouldn't
know to instantiate. I didn't have to write an adapter. I just had to
say "I happen to know that instances of this class will have this
trait".

I don't know if that's LBYL, EYV (Eat Your Vegetables), LBWBCTS (Look
Both Ways Before Crossing The Street), or what. I think it's just a
way of saying "I happen to know that this thing smells like a duck. It
doesn't say that it smells like a duck, but I know it smells like a
duck. And for everywhere that I expect to find the fine fragrance of
duck, this thing should be allowed." No adapters, no changing the base
classes, no meddling with method resolution order, just adding a
trait. The trait in this case is like an access pass - just an extra
thing worn around the neck that will grant you access to certain doors
and pathways. It doesn't change who you are or how you accomplish your
job.

MTAAFT (Maybe There's Another Acronym For This)?

-- 
Jeff Shell


More information about the Python-3000 mailing list