[Python-Dev] Alternative Implementation for PEP 292: Simple String Substitutions (original) (raw)

Barry Warsaw barry at python.org
Mon Aug 30 05:37:25 CEST 2004

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 . 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

More information about the Python-Dev mailing list