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

[Guido van Rossum]

On Sun, May 18, 2008 at 12:30 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> 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.

Hm, Martin is pretty convincing here. Before we go ahead and accept
.transform() and friends (by whatever name) we should look for
convincing use cases where the transformation is typically given by
some other input, rather than hard-coded in the app. (And cases where
there are two or three possibilities from a fixed menu don't count --
so that would rule out Content-transfer-encoding.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)