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

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('remotehost') 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