<p dir="ltr"><br>
On 15 Nov 2013 08:34, "Victor Stinner" <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I saw that Nick Coghlan documented codecs.encode() and<br>
> codecs.decode(), and changed the exception raised when codecs like<br>
> rot_13 are used on bytes.decode() and str.encode().<br>
><br>
> I don't like the functions codecs.encode() and codecs.decode() because<br>
> the type of the result depends on the encoding (second parameter). We<br>
> try to avoid this in Python.</p>
<p dir="ltr">The type signature of those functions is just object -> object (Similar to the way the 2.x convenience methods were actually basestring -> basestring).</p>
<p dir="ltr">> I would prefer to split the registry of codecs to have 3 registries:<br>
><br>
> - "encoding" (a better name can found): encode str=>bytes, decode bytes=>str<br>
> - bytes: encode bytes=>bytes, decode bytes=>bytes<br>
> - str:  encode str=>str, decode str=>str<br>
></p>
<p dir="ltr">You have to get it out of your head that codecs are just about text and and binary data. They're not: they're arbitrary type transforms, and MAL deliberately wrote the module that way.</p>
<p dir="ltr">> And add transform() and untransform() methods to bytes and str types.<br>
> In practice, it might be same codecs registry for all codecs just with<br>
> a new attribute.</p>
<p dir="ltr">This is completely the wrong approach. There's zero justification for adding new builtin methods for this use case - encoding and decoding are generic operations, they should use functions not methods.</p>

<p dir="ltr">What could be useful is allowing CodecInfo objects to supply an "expected input type" and an "expected output type" (ABCs and instance check overrides make that quite flexible).</p>
<p dir="ltr">><br>
> Examples:<br>
><br>
> - utf8: encoding<br>
> - zlib: bytes<br>
> - rot13: str<br>
><br>
> The result type of bytes.transform/untransform would be bytes, and the<br>
> result type of str.transform/untransform would be str.<br>
><br>
> I don't know which exception should be raised when a codec is used in<br>
> the wrong method. LookupError? TypeError "codec xxx cannot be used<br>
> with method xxx.xx"? Something else?</p>
<p dir="ltr">We already do this check in the existing convenience methods - it raises TypeError.</p>
<p dir="ltr">><br>
> codecs.encode/decode() documentation should be removed. The functions<br>
> should be kept, just in case if someone uses them.</p>
<p dir="ltr">No. They're part of the regression test suite, and have been since Python 2.4. They embody MAL's intended "arbitrary type transform library" approach. They provide a source compatible mechanism for using binary codecs in single code base Python 2/3 projects.</p>

<p dir="ltr">At this point, the only person that can get me to revert this clarification of MAL's original vision for the codecs module is Guido, since anything else completely fails to address the Python 3 adoption barrier posed by the current state of Python 3's binary codec support.</p>

<p dir="ltr">Note that the only behavioural changes in the commits so far were to exception handling - everything else was just docs. </p>
<p dir="ltr">The next planned commit (to restore the binary codec aliases) *is* a behavioural change - that's why I posted to the list about it (it received only two responses, both +1)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Victor<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>