On Fri, 15 Nov 2013 09:03:37 +1000
Nick Coghlan <ncoghlan at 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4