Guido van Rossum wrote: >>Templates are meant to template *text* data, so Unicode is >>the right choice of baseclass from a design perspective. > > Only in Python 3.0. We better start early to ever reach the point of making a clear distinction between text and binary data in P3k. > But even so, deriving from Unicode (or str) means the template class > inherits a lot of unwanted operations. While I can see that > concatenating templates probably works, slicing them or converting to > lowercase etc. make no sense. IMO the standard Template class should > implement a "narrow" interface, i.e. *only* the template expansion > method (__mod__ or something else), so it's clear that other > compatible template classes shouldn't have to implement anything > besides that. This avoids the issues we have with the mapping > protocol: when does an object implement enough of the mapping API to > be usable? That's currently ill-defined; sometimes, __getitem__ is all > you need, sometimes __contains__ is required, sometimes keys, rarely > setdefault. Looks like it's ont even clear what templating itself should mean... you're talking about a templating interface here, not an object type, like Barry is (for the sake of making Templates compatible to i18n tools like gettext). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 08 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
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