[Phillip J. Eby]
I've revised the draft today to simplify the terminology, discussing only
two broad classes of adapters. Since Clark's pending proposals for PEP 246
align well with the concept of extenders vs. independent adapters, I've
refocused my PEP to focus exclusively on adding support
On Thu, 2005-01-20 at 11:07, Guido van Rossum wrote:
I'd also like to explore ways of creating partial interfaces on the
fly. For example, if we need only the read() and readlines() methods
of the file protocol, maybe we could declare that as follows::
def foo(f: file['read',
At 03:07 AM 1/20/05 -0800, Guido van Rossum wrote:
Phillip worries that solving this with interfaces would cause a
proliferation of partial sequence interfaces representing the needs
of various libraries. Part of his proposal comes down to having a way
to declare that some class C implements some
[Guido van Rossum]
There's one other problem that Phillip tries to tackle in his
proposal: how to implement the rich version of an interface if all
you've got is a partial implementation (e.g. you might have readline()
but you need readlines()). I think this problem is worthy of a
solution,
Phillip, it looks like you're not going to give up. :) I really don't
want to accept your proposal into core Python, but I think you ought
to be able to implement everything you propose as part of PEAK (or
whatever other framework).
Therefore, rather than continuing to argue over the merits of
I've revised the draft today to simplify the terminology, discussing only
two broad classes of adapters. Since Clark's pending proposals for PEP 246
align well with the concept of extenders vs. independent adapters, I've
refocused my PEP to focus exclusively on adding support for extenders,
