[Python-Dev] Alternative Implementation for PEP 292: Simple String Substitutions

[Barry Warsaw]

On Thu, 2004-08-26 at 17:38, Raymond Hettinger wrote:

> My main issue with the current implementation is that we get no leverage
> from using a class instead of a function.  Though the API is fairly
> simple either way, it is easier to learn and document functions than
> classes.  We gain nothing from instantiation -- the underlying data
> remains immutable and no additional state is attached.  The only new
> behavior is the ability to apply the mod operator.  Why not do it in one
> step.

Weren't you the one who gave the Cheetah example?  What was interesting
about that was that the instance's attributes formed the substitution
namespace.  That's a use case I instantly liked.  So there you have
state attached to an instance.  Another case for that would be in i18n
applications where you might want to attach information such as the
gettext domain to the instance.  You might also want to build up the
namespace in several locations, and delay performing the substitution
until the last possible moment.  In all those cases you have state
attached to an instance (and would immediately invent such an instance
for those use cases if you didn't have one).

> One negative effect of the class implementation is that it inherits from
> unicode and always returns a unicode result even if all of the inputs
> (mapping values and template) are regular strings.  With a function
> implementation, that can be avoided (returning unicode only if one of
> the inputs is unicode).

To me that's not a disadvantage.  For i18n applications, unicode is the
only reasonable thing for human readable text.  str's are only useful
for byte arrays <wink>.  It's not a disadvantage for Jython or
IronPython either. :)

> Another minor advantage for a function is that it is easier to lookup in
> the reference.  If a reader sees the % operator being applied and looks
> it up in the reference, it is going to steer them in the wrong
> direction.  

The mod operator was chosen because that's what people are familiar
with, but it would probably be okay to pick a different method name.  I
think Guido's suggested using __call__() -- which I want to think more
about.

> This is doubly true if the Template instantiation is remote
> from the operator application.

Which, in some use cases, it most definitely will be.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040829/6f22ce3d/attachment.pgp