On 1/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > But this doesn't apply to the Python Standard Library, for example see
> > line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):".
> [...]
> > Being able to change imaplib to use basenumber instead of (int, float)
> > won't make it SIMPLER, but it will surely make it BETTER -- why should
> > a long be rejected, or a Decimal, for that matter?
>
> Right. I think this function should read
>
> if isinstance(date_time, str) and \
> (date_time[0],date_time[-1]) == ('"','"'):
> return date_time # Assume in correct format
>
> if isinstance(date_time, (tuple, time.struct_time)):
> tt = date_time
> else:
> tt = time.localtime(date_time)
So... arbitrary number-like objects should work, but arbitrary
sequence-like objects should fail? Hmmm. Maybe that "if
isinstance()" line should say "if hasattr(date_time, '__getitem__'):".
Am I sure? No. The original author of imaplib apparently got it
wrong, and Martin got it wrong, and they're both smarter than me.
Really this is just further proof that type-checking is a royal pain
in Python. Or rather, it's not hard to cover the builtin and stdlib
types, but it's hard to support "duck typing" too. Are we going about
this the right way? Options:
1. Redesign the API so each parameter has a clearly defined set of
operations it must support, thus eliminating the need for
type-checking. Drawback: An annoying API might be worse than the
problem we're trying to solve.
2. Write a set of imprecise, general-purpose type-checking functions
(is_real_number(v), is_sequence(v), ...) and use those. (They are
imprecise because the requirements are vague and because it's not
really possible to pin them down.) Drawback: Error-prone, compounded
by deceptively clean appearance.
3. Write very specific custom type-checking code each time you need
it (the imaplib approach). Drawbacks: Error-prone (as we've seen),
precarious, tedious, unreadable.
4. Use the "better-to-ask-forgiveness-than-permission" idiom.
Drawback: Potential bad behavior on error, again potentially worse
than the original problem.
Yuck. Does anyone have the answer to this one? Or is the problem not
as bad as it looks?
-j
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
