Implicit lists

[Christian Tismer]

Chad Netzer wrote:
> On Thu, 2003-01-30 at 19:28, Christian Tismer wrote:
> 
> 
>>In my opinion, the crux of this all is the decision
>>that strings are iterable.
> 
> 
> Ah, but I work with Numeric arrays a lot, which are also iterable, and
> which I like to package into tuple or lists for various reasons.  These
> same problems can crop up as well (must be careful to pass a sequence of
> arrays, rather than just an array, etc).  So it isn't just strings that
> present a problem.

Well, I don't take that argument.
Strings are used in an atomic manner
most of the time.
Lists/tuples as arguments are also typical
to be one dimensional. If they are not, the
user will probably take the time to read the
interface docs; (s)he should anyway.

With numeric arrays, it is *typical* to have
a multi dimensional array. In most cases, you
will want to have an array of a given dimensionality
as an argument, less likely a list of arrays.
IMHO, Numeric lacks a distinction between objects to be
seen as a whole and sequences, since this applies so
very recursively.

> Using variable parameters, you could build an interface that will accept
> single arguments (ie. foo(x) ), and would accept iterable objects or
> sequences as long as you explicitly specified that (ie. foo(*seq) ),
> while rejecting single arg sequences.  A bit ugly, but could be useful
> with lots of string/list/tuple mixes.

I think, with Numeric objects, which are iterable on so many
levels, it is insane to provide ambiguous function interfaces.
These objects are so overloaded with flexibility, that I think
it would be better to do all the pre-shaping inside these objects
and then pass singletons of them to functions.

This appears to be a situations where two concepts of
flexibility are fighting each other.

if-the-interface-is-difficult-then-it's-wrong - ly y'rs - chris