On Fri, 15 Nov 2013 09:03:37 +1000
Nick Coghlan <ncogh...@gmail.com> wrote:
>
> > 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.
>
> 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.
I'm sorry, I disagree. The question is what use case it is solving, and
there's zero benefit in writing codecs.encode("zlib") compared to e.g.
zlib.compress().
A transform() or untransform() method, however, allows for a much more
convenient spelling, with easy cascading, e.g.:
b.transform("zlib").transform("base64")
In other words, there's zero justification for codecs.encode() and
codecs.decode(). The fact that the codecs machinery works on arbitrary
object transformation is a pointless genericity, if it doesn't bring
any additional convenience compared to the canonical functions in their
respective modules.
> 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.
I'd like to challenge your assertion that your change addresses
anything.
It's not easier to change b.encode("zlib") into codecs.encode("zlib",
b), than it is to change it into zlib.compress(b).
Regards,
Antoine.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
