[PATCH] allow partial replace in string.Template

[Stefan Behnel]

Hi!

Here's a trivial patch against Lib/string.py that adds two new methods. The
first replaces the template by a partially resolved substitution and the
second creates a new, partially substituted template. I find those two useful
enough for integration in the stdlib, especially the replacing one is very
useful when pre-replacing some placeholders outside of string generation loops
or when building a string from a template step by step.

Maybe the method names need some discussion. Also, the creation of a new
Template does not handle sub-classes. I didn't know the best was to do this.
Use type(self)? That doesn't necessarily mean the constructor of that type
takes the same arguments...

Any comments?

Stefan


--- Lib/string.py~ 2004-11-01 04:52:43.000000000 +0100
+++ Lib/string.py 2005-02-14 10:41:41.000000000 +0100
@@ -145,6 +145,12 @@
raise ValueError('Invalid placeholder in string: line %d, col %d' %
(lineno, colno))

+ def partial_replace(self, *args, **kwargs):
+ self.template = self.safe_substitute(*args, **kwargs)
+
+ def partial_substitute(self, *args, **kwargs):
+ return Template( self.safe_substitute(*args, **kwargs) )
+
def substitute(self, *args, **kws):
if len(args) > 1:
raise TypeError('Too many positional arguments')

--- Lib/string.py~ 2004-11-01 04:52:43.000000000 +0100
+++ Lib/string.py 2005-02-14 10:41:41.000000000 +0100
@@ -145,6 +145,12 @@
raise ValueError('Invalid placeholder in string: line %d, col %d' %
(lineno, colno))

+ def partial_substitute(self, *args, **kwargs):
+ return Template( self.safe_substitute(*args, **kwargs) )
+
+ def partial_replace(self, *args, **kwargs):
+ self.template = self.safe_substitute(*args, **kwargs)
+
def substitute(self, *args, **kws):
if len(args) > 1:
raise TypeError('Too many positional arguments')

 

[Nick Coghlan]

a) Patches are more likely to be looked at if placed on the SF patch tracker.

b) I don't quite see the point, given how easy these are to spell using the
basic safe_substitute. You're replacing one liners with one-liners.

Cheers,
Nick.

 

[Stefan Behnel]

Nick Coghlan wrote

a) Patches are more likely to be looked at if placed on the SF patch
tracker.

see your own b), I wanted to discuss them first.

b) I don't quite see the point, given how easy these are to spell using
the basic safe_substitute. You're replacing one liners with one-liners.

Still, when I first tried out the Template class, I immediately stumbled over
the fact that the substitute methods always return strings, and never Template
objects. While it makes sense for their primary purpose, it totally restricts
the usage of this module to one-show operations.

Being able to partially evaluate the Template is something that is absolutely
missing in the implementation. I consider that a bug that should be fixed for
2.5 at latest.

Stefan

 

[Nick Craig-Wood]

a) Patches are more likely to be looked at if placed on the SF patch tracker.

b) I don't quite see the point, given how easy these are to spell using the
basic safe_substitute. You're replacing one liners with one-liners.

c) add a documentation patch

d) add a test suite patch

 

[Nick Coghlan]

Nick Coghlan wrote



see your own b), I wanted to discuss them first.

Fair enough.

Still, when I first tried out the Template class, I immediately stumbled
over the fact that the substitute methods always return strings, and
never Template objects. While it makes sense for their primary purpose,
it totally restricts the usage of this module to one-show operations.

Except that it is easy to turn a string into a template using a constructor. . .

However, now that I think more about your 'partial_substitute' method it does
make sense as an alternative constructor:

@classmethod
def from_template(*args, **kwds):
cls, orig = args[:2]
return cls(orig.safe_substitute(*args[2:], **kwds))

Usable as:
new_templ = Template.from_template(orig_templ, *args, **kwds)

Versus:
new_templ = Template(orig_templ.safe_substitute(*args, **kwds))

Mutating the template in place seems questionable. Rebinding the name with the
above constructor would be more appropriate, IMO.

Hmm - I'm unconvinced, but it's probably still worth posting a patch and sending
it in Barry Warsaw's direction.

Cheers,
Nick.