[Python-Dev] Single- vs. Multi-pass iterability

[Alex Martelli]

On Friday 12 July 2002 02:43 am, Guido van Rossum wrote:
> > The real reason to be able to introspect is so that you can handle both
> > kinds.
> > Even if you're willing to destroy the data by examining it, if you know
> > you have a single-pass sequence, you might need to copy its elements into
> > a multi-pass sequence (e.g. file.lines()) in order to get your work done.
>
> Hm.  I think it's just as good to make it the responsibility of the
> caller to pass a multi-iterable.  There could be a standard tool that
> takes a single-iterable and produces a multi-iterable.

At the risk of sounding like a broken record -- doesn't protocol adaptation
stand out as a good way to package up such a "standard tool"?  Why
should we keep inventing a variety of different ways to ask the same kind
of service -- "Here is an object X, please return it or a wrapper on it in 
such a way that it satisfies protocol Y, if possible"...?

In this specific case, Y is "a multi-iterable".  Last time the subject came
up in this list, as I recall, Y was "usable as an index on a sequence".

Having protocol-adaptation machinery would not save the work of designing
protocols and adapters, and there would still be the need to decide case
by case "do we want to standardize this specific adaptation".  However, it
would save the work involved in "given that we DO want to standardize
this adaptation, how do we dress it up" -- how do we present the service
to client-code.  The greatest benefits might be to authors of client code (and
aren't we all, from time to time?-) -- reducing the amount of learning 
involved with each protocol-adaptation to "what is the protocol Y I want".

I don't think it's strictly necessary for Y to be "an interface", and thus 
that protocol adaptation must necessarily wait for interfaces to become a
recognized and formalized Python concept.  I think that accepting any type
as "a protocol" would be fine, and pragmatically equivalent to requiring a
protocol to be "an interface".


Alex