[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
Ian Bicking
ianb at colorstudy.com
Sat Feb 18 01:00:09 CET 2006
Josiah Carlson wrote:
>>>If some users
>>>can't understand this (passing different arguments to a function may
>>>produce different output),
>>
>>It's worse than that. The return *type* depends on the *value* of
>>the argument. I think there is little precedence for that: normally,
>>the return values depend on the argument values, and, in a polymorphic
>>function, the return type might depend on the argument types (e.g.
>>the arithmetic operations). Also, the return type may depend on the
>>number of arguments (e.g. by requesting a return type in a keyword
>>argument).
>
>
> You only need to look to dictionaries where different values passed into
> a function call may very well return results of different types, yet
> there have been no restrictions on mapping to and from single types per
> dictionary.
>
> Many dict-like interfaces for configuration files do this, things like
> config.get('remote_host') and config.get('autoconnect') not being
> uncommon.
I think there is *some* justification, if you don't understand up front
that the codec you refer to (using a string) is just a way of avoiding
an import (thankfully -- dynamically importing unicode codecs is
obviously infeasible). Now, if you understand the argument refers to
some algorithm, it's not so bad.
The other aspect is that there should be something consistent about the
return types -- the Python type is not what we generally rely on,
though. In this case they are all "data". Unicode and bytes are both
data, and you could probably argue lists of ints is data too (but an
arbitrary list definitely isn't data). On the outer end of data might
be an ElementTree structure (but that's getting fishy). An open file
object is not data. A tuple probably isn't data.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Python-Dev
mailing list