[Python-Dev] Add transform() and untranform() methods

[Nick Coghlan]

On 15 Nov 2013 09:11, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
>
> On 15 Nov 2013 08:42, "Victor Stinner" <victor.stinner at gmail.com> wrote:
> >
> > Oh, I forgot to mention that I sent this email in reaction to this
issue:
> >
> > http://bugs.python.org/issue19585
> >
> > Modifying the critical PyFrameObject because the codecs API raises
> > surprising errors doesn't sound correct. I prefer to fix how codecs
> > are used, than modifying the PyFrameObject.
> >
> > For more information, see the issue #7475 which a long history (4
> > years) and many messages. Martin von Loewis wrote "I would still be
> > opposed to such a change, and I think it needs a PEP." and I still
> > agree with him on this point. Because they are different opinions and
> > no consensus, a PEP is required to explain why we took this decision
> > and list rejected alternatives.
> >
> > http://bugs.python.org/issue7475
>
> Martin wrote that before it was pointed out there were existing functions
to handle the problem (I was asking for a PEP back then, too).
>
> I posted my plan for dealing with this months ago without receiving any
complaints, and I'm annoyed you waited until I had actually followed
through and implemented it to complain about it and ask for Python 3's
binary codec support to stay broken instead :P

Something I *would* be entirely happy to do is write a retroactive PEP
after beta 1  is out the door, explaining the history of this issue in a
more coherent form than the comment history on issue 7475 and the many
child issues it spawned.

This would also provide a better launching point for other enhancements in
Python 3.5 (frame annotations to remove the need for the exception chaining
hack and better input validation mechanisms for codecs that allow the
convenience methods to check that case explicitly rather than relying on
the exception chaining).

Cheers,
Nick.

>
> (Starting a new thread instead of replying to the one where I
specifically asked about taking the next step does nothing to improve my
mood)
>
> Regards,
> Nick.
>
> >
> > Victor
> >
> > 2013/11/14 Victor Stinner <victor.stinner at gmail.com>:
> > > Hi,
> > >
> > > I saw that Nick Coghlan documented codecs.encode() and
> > > codecs.decode(), and changed the exception raised when codecs like
> > > rot_13 are used on bytes.decode() and str.encode().
> > >
> > > I don't like the functions codecs.encode() and codecs.decode() because
> > > the type of the result depends on the encoding (second parameter). We
> > > try to avoid this in Python.
> > >
> > > I would prefer to split the registry of codecs to have 3 registries:
> > >
> > > - "encoding" (a better name can found): encode str=>bytes, decode
bytes=>str
> > > - bytes: encode bytes=>bytes, decode bytes=>bytes
> > > - str:  encode str=>str, decode str=>str
> > >
> > > And add transform() and untransform() methods to bytes and str types.
> > > In practice, it might be same codecs registry for all codecs just with
> > > a new attribute.
> > >
> > > Examples:
> > >
> > > - utf8: encoding
> > > - zlib: bytes
> > > - rot13: str
> > >
> > > The result type of bytes.transform/untransform would be bytes, and the
> > > result type of str.transform/untransform would be str.
> > >
> > > I don't know which exception should be raised when a codec is used in
> > > the wrong method. LookupError? TypeError "codec xxx cannot be used
> > > with method xxx.xx"? Something else?
> > >
> > > codecs.encode/decode() documentation should be removed. The functions
> > > should be kept, just in case if someone uses them.
> > >
> > > Victor
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131115/cba56bd1/attachment.html>