> > 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. The introduction of a bytes type in Python 2.5 should be a good start. > > 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). I don't know zip about i18n or gettext. But I thought we had plenty of time since Barry has offered to withdraw the PEP 292 implementation for 2.4? -- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
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