On 20 November 2013 23:38, Walter Dörwald <wal...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
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
