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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
