<p dir="ltr"><br>
On 16 Nov 2013 02:36, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> On Sat, 16 Nov 2013 00:46:15 +1000<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> > On 16 November 2013 00:04, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> > >> Rather than the more useful:<br>
> > >><br>
> > >> >>> b"abcdef".decode("hex")<br>
> > >> Traceback (most recent call last):<br>
> > >>   File "<stdin>", line 1, in <module><br>
> > >> TypeError: 'hex' decoder returned 'bytes' instead of 'str'; use<br>
> > >> codecs.decode() to decode to arbitrary types<br>
> > ><br>
> > > I think this may be confusing.  TypeError seems to suggest that the<br>
> > > parameter type sent by the user to the method is wrong, which is not<br>
> > > the actual cause of the error.<br>
> ><br>
> > The TypeError isn't new,<br>
><br>
> Really? That's not what your message said.</p>
<p dir="ltr">The second example in my post included restoring the "hex" alias for "hex_codec" (its absence is the reason for the current "unknown encoding" error). The 3.2 and 3.3 error message for a restored alias would have been "TypeError: 'hex' decoder returned 'bytes' instead of 'str'", which I agree is confusing and uninformative - that's why I added the reference to the module level functions to the output type errors *before* proposing the restoration of the aliases. </p>

<p dir="ltr">So you can already use "codecs.decode(s, 'hex_codec')" in Python 3, you just won't get a useful error leading you there if you use the more common 'hex' alias instead.</p>
<p dir="ltr">To address Serhiy's security concerns with the compression codecs (which are technically independent of the question of restoring the aliases), I also plan to document how to systematically blacklist particular codecs in an application by setting attributes on the encodings module and/or appropriate entries in sys.modules.</p>

<p dir="ltr">Finally, I now plan to write a documentation PEP that suggests clearly splitting the codecs module docs into two layers: the type agnostic core infrastructure and the specific application of that infrastructure to the implementation of the text encoding model.</p>

<p dir="ltr">The only functional *change* I'd still like to make for 3.4 is to restore the shorthand aliases for the non-Unicode codecs (to ease the migration for folks coming from Python 2), but this thread has convinced me I likely need to write the PEP *before* doing that, and I still have to integrate ensurepip into pyvenv before the beta 1 deadline.</p>

<p dir="ltr">So unless you and Victor are prepared to +1 the restoration of the codec aliases (closing issue 7475) in anticipation of that codecs infrastructure documentation PEP, the change to restore the aliases probably won't be in 3.4. (I *might* get the PEP written in time regardless, but I'm not betting on it at this point).</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Regards<br>
><br>
> Antoine.<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>