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

M.-A. Lemburg mal at egenix.com
Mon May 19 19:03:53 CEST 2008


On 2008-05-19 17:14, Guido van Rossum wrote:
> 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.)

The .transform() methods are meant as interface to same type
codecs in general, not just compression algorithms.

They are convenience methods to the codecs registry
with the added benefit of applying type checks which the codecs
registry does not guarantee since it only manages codecs.

Of course, you can write everything directly against the codec
registry or some other specialized interface, but that's not
really what we're after here.

The methods are meant to make code easy to write in the
general use case, without having to worry about special
parameters or finding the right module and function names.

Motivation: When was the last time you used a gzip compression
option (ie. yes there are options, but do you use them in the
general use case) ? Can you write code that applies UU encoding
without looking up the details in the documentation (ie. there
is a module for doing UU-encoding in the stdlib, but what's it's
name, what's the function, does it need extra logic) ?

The motivation is not driven by having the need to pass a
configuration parameter to a .transform() method.

It's being able to write

     str.transform('gzip').transform('uu')

which doesn't require knowledge about the modules doing the actual
work behind the scenes.

We're not adding those methods because there's no other way
to get the functionality. It's all about usability, readability
and PEP20 ("Beautiful is better than ugly.").

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 19 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611


More information about the Python-3000 mailing list