homepage

Python's $-style templating is wired for optional
case-insensitivity under the hood, but doesn't expose
this via the API. The attached patch (against trunk/
r50813) adds a new optional argument to turn this
behavior on, and includes doc and tests.

Logged In: YES 
user_id=340931
Warning: I've discovered that I introduced a bug. New patch
forthcoming.

Logged In: YES 
user_id=340931
I've replaced the patch with one that polishes off a few
bugs and ambiguities, with accompanying tests and doc.

Logged In: YES 
user_id=340931
(BTW, new patch is against trunk/ r51008)

Logged In: YES 
user_id=849994
The patch looks very thorough and complete, I will try to
look into it after 2.5 is out.
Don't let that prevent you reviewing 5 patches, Chad ;-)

Logged In: YES 
user_id=80475
Barry, is this something you want or is it at odds with the
notion of "simplified templating"?

Logged In: YES 
user_id=12800
I'm not psyched about the patch. First, I've always thought
that case insensitivity ought to be handled by the mapping
from which the keys are being extracted and by setting the
idpattern. Second, I definitely don't like adding the
case_sensitive argument to substitute() and
safe_substitute(). Because it lives in the same namespace as
kws it makes for icky rules on resolving any conflicts.
Is there a reason why the existing mechanisms are insufficient?

Logged In: YES 
user_id=340931
Thanks for your responses, all.
> Is there a reason why the existing mechanisms are 
> insufficient?
The problem is kws: you can't customize it from the outside
like you can the mapping argument. If we replaced _multimap
with mapping.update(kws), then we'd have our hook and I
think I'd be satisfied.
Would you be any more psyched about that patch? :)

Logged In: YES 
user_id=12800
Yes, that would be much more acceptable!

Logged In: YES 
user_id=340931
Ok, here it is! I added a test but wasn't sure this
warranted a doc change. Cf.:
 http://docs.python.org/dev/lib/node40.html 

Logged In: YES 
user_id=12800
Looks good to me. Remind us when we fork the trunk.

Logged In: YES 
user_id=80475
The replacement of _multimap is a semantic change. 
Formerly, a dictionary passed in as a positional argument is
left unmolested; now, it is mutated to reflect kwds. Also,
the _multimap setup is an O(1) step while the update()
approach is O(n). Also, the current implementation only
requires the positional argument to support __getitem__();
now, it requires a more fully compliant duck (one that
provides an .update() method).
- mapping = _multimap(kws, args[0])
+ mapping = args[0]
+ mapping.update(kws)
Current behavior:
>>> t = Template('the $speed brown')
>>> d = dict(speed='quick')
>>> t.safe_substitute(d, speed='slow')
'the slow brown'
>>> d
{'speed': 'quick'}
After the patch, it returns {'speed': 'slow'}.
Likewise the following now works, but would fail after the
patch:
>>> t = Template('the $speed brown')
>>> class D:
	def __getitem__(self, key):
		return 'quick'
>>> t.safe_substitute(D(), speed='slow')
'the slow brown'
The whole approach is misguided, and the use case itself is
suspect. If some change is warranted, consider a cleaner,
more general-purpose solution like having an optional key=
argument to the Template constructor for pre-processing keys:
>>> t = Template('the $speed brown', key=str.lower)

Logged In: YES 
user_id=340931
Raymond,
Thanks for the attention to detail. But could you help me
understand what it means that "the whole approach is
misguided, and the use case itself is suspect[?]" The
customization use case? The approach to customization via
the mapping argument?
In other words, I understood the mapping argument to already
be a customization mechanism; otherwise, the methods could
use kws only. So wouldn't a 'key' argument be *more*
complicated, introducing additional customization semantics
instead of working with what's already there?
My concern, though, is that by using _multimap instead of
update, we limit the customizations one may perform from the
outside. Why this limitation? Performance? Ok. So then it's
a matter of adjudicating a performance/feature trade-off?

Anybody interested in this, if not I'll close it.

Closing as noone has responded.

I don't think this closure was appropriate. The idea was accepted twice and argued against once, so it isn't dead (it's just resting).

I seconded Raymond. Now the approach is argued against twice. And the patch itself is outdated. I suggest to close this issue. If somebody want to implement Raymond's idea, his can reopen this issue or open new issue.

Agreed with Serhiy. Raymond's approach is nicer, but I'm still not convinced about the use case. Closing.
If someone wants to run with this again, an updated patch would be needed, and the issue could be reopened, but I also suggest following through with Raymond's idea.