[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