Implicit lists

[Erik Max Francis]

Dale Strickland-Clark wrote:

> Alex Martelli <aleax at aleax.it> wrote:
> 
> > A class is string-like if it acts like a string.  If a
> > class lets its instances be concatenated to strings, it's
> > pretty string-like -- all of str, unicode and UserString
> > do, and no other type that's either built-in or the standard
> > library.  Making this easily checked feature the single
> > discriminant of "string-likeness" appears quite OK to me
> > for most purposes.  You can wrap the test into highly readable
> > form by the simple trick of defining a function;-)...e.g.:
> >
> > def isstringlike(x):
> >     try: return x+'!'
> >     except TypeError: return False
> 
> There's a bit of a language deficiency here if you have to resort to
> this type of obscure trick.

I disagree.  I think having to resort to that "obscure trick" too often
reveals a program design problem, not a language deficiency.

In dynamically-typed languages like Python, overloading functions (which
is I presume the crux of where you're doing this test) based on type
usually isn't a great idea.  Usually it's better to have two
functions/methods instead.

I will freely admit to on occasion breaking this dictum myself, but
usually I do it in the reverse way:  I'll check if it it's a certain
type, and if not, make the more general assumption; e.g., for a function
intended to include another file in some capacity, I'll might check if
it's a string, then treat that as a filename; if it's not a string, I'll
presume it's a filelike object and just continue on.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ The great artist is the simplifier.
\__/ Henri Amiel
    Sade Deluxe / http://www.sadedeluxe.com/
 The ultimate Sade encyclopedia.