[Python-3000] Abilities / Interfaces

[Phillip J. Eby]

At 07:53 AM 11/22/2006 -0800, Guido van Rossum wrote:
>  If there were an
>interface that means "Behaves like a string" then those few brave
>souls who write their own string implementation from scratch could
>just claim to implement it and their string objects would be welcome
>everywhere.

Okay, make an 'as_string()' generic function that returns a string (or 
subclass thereof), or fails.  Then, allow the use of one generic function 
as a type specifier for another, so that if I want to make a 'flatten()' 
function, I can 'addmethod(flatten, lambda ob: ob, as_string)' to mean "the 
flatten() of something that can be passed to as_string is the object itself".


>having a standard generic function that takes a string or a stream and
>returns a stream -- that is indeed a handy thing to have, except we
>still have to know whether the argument was a string or not, because
>if we open it, we want to close it, but if we were passed a stream, we
>*don't* want to close it.

Actually, I'd say you'd have a generic function that returns either an 
adapter or a context manager.  The stream adapter would have a no-op 
close(), or the stream context manager would do nothing on exit.  (e.g. 
"with stream_for(string_or_stream) as f:".)


>Now, due to duck typing, if you just *use* numbers, and the numpy
>folks have done their job, things will just work -- this is your
>argument about using generic operations. But as soon as any type
>testing happens (e.g. when writing an API that takes either a number
>of a string or a list of numbers),

Isn't this basically just another flatten() example?  The only time you'd 
need special casing for numbers would be if you had an iterable number 
type; otherwise, why even bother checking if they're numbers?


>perhaps numbers and strings (types with rich APIs that are only rarely
>re-implemented from scratch) are special cases?

The Pedroni argument is oriented towards types like file, list, and dict, 
that have a rich API but are more frequently re-implemented from scratch 
and more likely to be missing methods.