Implicit lists
holger krekel
pyth at devel.trillke.net
Thu Jan 30 19:06:12 EST 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
try:
return somedict[key]
except KeyError:
...
because this *positively* checks for a problem and
takes appropriate action. Whereas
try:
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.
holger
More information about the Python-list
mailing list