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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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