Implicit lists

[Christian Tismer]

Delaney, Timothy wrote:
> From: Christian Tismer [mailto:tismer at tismer.com]
> 
> In my opinion, the crux of this all is the decision
> that strings are iterable.
> The number of use cases which I have seen so far is much
> shorter than this thread.
> Strings are much more often used as solid objects.
> I'm pretty sure Guido would remove the sequence-ness
> of strings in Python 3000, even to avoid this kind
> of problems.
> 
> 
> Whilst I've always liked that strings are iterable in Python, it does lead
> to complexity when you want to treat them specially.

How many of your programs *do* use an iteration over strings?
I have one or two, from the early first contact with Python.
Then I always was busy to defend strings as sequences.

> Additionally, the new semantics of 'in' for strings in 2.3 does suggest a
> lessening of the sequence-like behaviour of strings.

Absolutely.

> However, there has been a move to making *more* things iterable, not less.
> Whilst in general this is nice, it does mean that there are more
> opportunities for invalid objects to be processed by library routines.

I'm not against having more that makes sense.
But as stated elsewhere, we should at the same
time have less of the non-sense.
We are probably deprecating apply in favor of "*"/"**"
function calling, since it simplifies matters.
Strings as sequences do not simplify at all.
Without them, this thread would be non-existant
(as it should be).

> I would say, if you absolutely *must* have a list, document as such and do a
> typecheck. If someone wants to pass a non-list, they must convert it to a
> list by whatever method is appropriate.

Sure. Explicit, simple arguments are better than
implicit coercions.
If you need to have lists or tuples, I prefer to
do positive tests for them, instead of allowing
any iterable. It is then on the user's side to
supply the correct type or a coercion.

> But in general, wider interfaces are preferable.

Explicit intefaces would be a delight, btw.

ciao - chris