> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
