[Python-3000] PEP 3138- String representation in Python 3000

"Martin v. Löwis" martin at v.loewis.de
Sun May 18 09:30:38 CEST 2008


> Selecting an encoding is the kind of thing that will often come from the
> application's environment, or user preferences or configuration options,
> rather than being hardcoded at development time.

And that's the main difference why having encode/decode is a good idea,
and having transform/untransform is a bad idea.

Encoding names are in configuration data all the time, or even in the
actual data (e.g. in MIME); they rarely are in configuration.

You typically *don't* read the name of transformations from a
configuration file. And even if they are in configuration, you
typically have a fixed set of options, rather than an extensible
one.

> With a flat,
> string-based codec namespace, those things are trivial to look up.
> Having to mess around with __import__ just to support a "choose
> compression method" configuration option would be fairly annoying.

I wouldn't mess with import:

import gzip, bz2
compressors = {"gzip":gzip.StreamCompressor,
               "bzip2":bz2.BZ2Compressor}
decompressors={"gzip":gzip.StreamDecompressor,
               "bzip2":bz2.BZ2Decompressor}

It's not that people invent new compression methods every day.

OTOH, these things have often more complex parameters than just
a name; e.g. the compressors also take a compression level. In
these cases, using

  output_to = compressors[name](compresslevel=complevel)

could work fine (as both might happen to support the compresslevel
keyword argument).

> The case for the special namespace is much stronger for the actual
> unicode encodings, but it still has at least some force for the
> bytes->bytes and str->str transforms.

Not to me, no.

Regards,
Martin


More information about the Python-3000 mailing list