Implicit lists

holger krekel pyth at
Fri Jan 31 01:06:12 CET 2003

Alex Martelli wrote:
> holger krekel wrote:
> > Alex Martelli wrote:
> >> holger krekel wrote:
> >>    ...
> >> > I think it's safer to skip "iteration" with an explicit
> >> > 
> >> >     isinstance(arg, (str, unicode))
> >> > 
> >> > check.  It's also simpler to read and understand.
> >> 
> >> And it breaks *EVERY* use of UserString -- a module in the
> >> standard Python library, even!!! -- not to mention user-coded
> >> string-like types and classes.  *shudder*.
> > 
> > sorry, but fewer scream-emoticons would suffice to make
> > your point.
> Not for an Italian forced to express himself _without_ moving
> his hands about.

Still it can and actually does setup discussion hierarchies.

> > However, it feels like an implicit kind of type-check.
> Your feelings are a bit off here -- because types work
> differently, e.g. UserString has NO type connection with
> str -- but not by much: what it is is a PROTOCOL-check --

Right, that's what i meant with 'kind of'.  Sometimes i try 
to not introduce too many concepts at once.  So let me 
restate my key point from the last mail:

The general pythonic "avoid checking for types or existence
of methods. instead just try and catch exceptions" does 
not always apply when you want to *prevent* something
instead of react to erranonous behaviour.  

It's actually quite common to check for str/unicode 
even in the standard lib and there is types.StringTypes 
kind-of-stating that.  Of course you could argue that 
this is all wrong and everybody should check 
for  obj+"" not throwing an exception, instead. 

Note, though, that you can not refer to common practice like

            return somedict[key]
        except KeyError:
because this *positively* checks for a problem and
takes appropriate action. Whereas

            obj + ""
        except TypeError:
            # ...

tries to infer knowledge aka "must be some string"
from a *missing* problem/exception.  That's a lot
weaker and can produce surprises.


More information about the Python-list mailing list