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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4