On Tue, Nov 19, 2013 at 05:28:48PM -0800, Jim J. Jewett wrote:
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
Serhiy Storchaka wrote:
If the transform() method will be added, I prefer to have only
one transformation method and specify a direction by the
On Wed, Nov 20, 2013 at 11:03 PM, Steven D'Aprano st...@pearwood.info wrote:
I *will* get confused over which
direction is encoding and which is decoding. (Removing .decode()
from the (unicode) str type in 3 does help a lot, if I have a Python 3
interpreter running to check against.)
It took
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
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
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
Serhiy Storchaka wrote:
If the transform() method will be added, I prefer to have only
one transformation method and specify a direction by the
transformation name (bzip2/unbzip2).
Me too. Until I consider special cases
My thought on this for the day, for what it's worth:
Anything that doesn't have directions clearly identifiable
as encoding and decoding maybe shouldn't be called
a codec?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
