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

[Guido van Rossum]

On Mon, May 19, 2008 at 3:27 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Guido van Rossum writes:
>
>  > 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.)
>
> I don't understand the motivation for this restriction.  I think we do
> not want to share names across categories, so the size of any given
> category is not important, it's the whole registry that is useful.  If
> people want to filter on category, the registry entries could be given
> a 'category' attribute.
>
> Aside from that, the kind of application I have in mind is indeed
> something like the email module and its clients (like Mailman).
> Things like
>
> language_charset_map = { 'japanese' : 'iso-2022-jp',
>                         'english' : 'iso-8859-1',
>                         'russian' : 'koi8-r',
>                         ... }
>
> charset_transfer_encoding_map = { 'iso-2022-jp' : 'base64',
>                                  'iso-8859-1' : 'quoted-printable',
>                                  'koi8-r' : 'base64',
>                                  ... }
>
> mime_type_compression_map = { 'text/plain' : None,
>                              'img/bmp' : 'gzip',
>                              ... }
>
> with the almost obvious definition of transform_mime_body().
>
> This kind of table is often given in a file accessed by non-Python-
> programmers.  For example, for encodings that are not mostly ASCII,
> gzipped base64 may be a very economical way to transmit (and store) a
> text part.  However, a non-English list that transmits a lot of code
> might prefer quoted-printable to allow the code to be analyzed by some
> kind of robot (obviously a legacy app!), and many lists will have
> strong preferences between UTF-8 and a legacy encoding.  Japanese
> companies often have corporate encodings containing characters not
> available in JIS (and sometimes not in Unicode).  A list dedicated to
> image processing may want to add image/* formats that haven't yet been
> registered with the IANA, etc.
>
> On the Mailman lists it is a FAQ that people don't understand the
> difference between 'None' and None.  I don't think we can avoid None,
> True, and False, but for many Mailman admins the difference between
> 'gzip' and Compressors.gzip.compress is non-obvious and annoying.
> Giving string names to all these transforms would make the
> administration interface perceptibly more regular.

There's no reason that for this pretty unusual and specific case you
couldn't have your own function that is controlled by the string value
read from the map edited by the list admin.

I think the real abomination here is to expect list admins to use
Python syntax at all.

> On the other hand, suppose we have a web interface for configuration
> so that the admins don't ever see the difference between a codec
> registry key and a Python identifier.  Do we want to expose all the
> possible compressors, codecs, transfer encodings, and what not in the
> module that provides the configuration UI so that the list of names
> can be provided?  How does the web interface avoid needing to know all
> of those in advance?  How does the web interface know which functions
> are which (eg, compressor v. decompressor)?
>
> Of course the same questions apply to a registry, but as functionality
> (answers to those questions) is added to the registry, the changes
> needed to take advantage of it are much more localized and less
> invasive than, say, requiring "compressors" to provide "compress" and
> "uncompress" functions or methods, and a standard set of options.
>
> The main thing that I sympathize with in Martin's post is the issue of
> options to transforms, but it seems to me that keyword arguments deal
> with that clearly and flexibly.
>
>



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