[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]

[Ian Bicking]

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