Jason Orendorff wrote:
> 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?
It's not as bad. There is nothing wrong with restricting the set of
acceptable types if callers would have no problems to convert their
input into one of the acceptable types.
In the imaplib example, requesting that a broken-down time is passed
as a tuple or a time.struct_time is not too hard for a caller.
It will be formatted as
dt = time.strftime("%d-%b-%Y %H:%M:%S", tt)
so it needs to have the right number of fields. Callers having
other kinds of sequence can easily use tuple(L) to convert their
data into what the function accepts.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4