[Python-Dev] Which direction is UnTransform? / Unicode is different

Nick Coghlan ncoghlan at gmail.com
Wed Nov 20 14:44:57 CET 2013


On 20 November 2013 23:38, Walter Dörwald <walter at livinglogic.de> wrote:
> On 20.11.13 02:28, Jim J. Jewett wrote:
>
>> [...]
>>
>> Instead of relying on introspection of .decodes_to and .encodes_to, it
>> would be useful to have charsetcodecs and tranformcodecs as entirely
>> different modules, with their own separate registries.  I will even
>> note that the existing help(codecs) seems more appropriate for
>> charsetcodecs than it does for the current conjoined module.
>
>
> I don't understand how a registry of transformation functions would simplify
> code. Without the transform() method I would write:
>
>    >>> import binascii
>    >>> binascii.hexlify(b'foo')
>    b'666f6f'
>
> With the transform() method I should be able to write:
>
>    >>> b'foo'.transform("hex")
>
> However how does the hex transformer get registered in the registry? If the
> hex transformer is not part of the stdlib, there must be some code that does
> the registration, but to get that code to execute, I'd have to import a
> module, so we're back to square one, as I'd have to write:
>
>    >>> import hex_transformer
>    >>> b'foo'.transform("hex")
>
> A way around this would be some kind of import magic, but is this really
> neccessary to be able to avoid one import statement?

Could we please move discussion of hypothetical future divisions of
the codec namespace into additional APIs to python-ideas? We don't
even have consensus to restore the codecs module to parity with its
Python 2 functionality at this point, let alone agreement on adding
more convenience APIs for functionality that we have core developers
arguing shouldn't be restored at all.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list