Guido van Rossum added the comment:
str.decode() and bytes.encode() are not coming back.
Any proposal had better take into account the API design rule that the *type*
of a method's return value should not depend on the *value* of one of the
arguments. (The Python 2 design failed this test, and that's why we changed
it.)
It is however fine to let the return type depend on one of the argument
*types*. So e.g. bytes.transform(enc) -> bytes and str.transform(enc) -> str
are fine. And so are e.g. transform(bytes, enc) -> bytes and transform(str,
enc) -> str. But a transform() taking bytes that can return either str or
bytes depending on the encoding name would be a problem.
Personally I don't think transformations are so important or ubiquitous so as
to deserve being made new bytes/str methods. I'd be happy with a convenience
function, for example transform(input, codecname), that would have to be
imported from somewhere (maybe the codecs module).
My guess is that in almost all cases where people are demanding to say e.g.
x = y.transform('rot13')
the codec name is a fixed literal, and they are really after minimizing the
number of imports. Personally, disregarding the extra import line, I think
x = rot13.transform(y)
looks better though. Such custom APIs also give the API designer (of the
transformation) more freedom to take additional optional parameters affecting
the transformation, offer a set of variants, or a richer API.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
