On Mon, 2004-08-30 at 01:48, Raymond Hettinger wrote: > By not inheriting from unicode, the bug can be fixed while retaining a > class implementation (see sandbox\curry292.py for an example). > > But, be clear, it *is* a bug. > > If all the inputs are strings, Unicode should not magically appear. See > all the other string methods as an example. But the Template classes aren't string methods, so I don't think the analogy is quite right. Because the template string itself is by definition a Unicode, it actually makes more sense that everything its mod operator returns is also a Unicode. So I still don't think it's a bug. > Someday, all will be > Unicode, until then, some apps choose to remain Unicode free. Also, > there is a build option to not even compile Unicode support -- it would > be a bummer to have the $ templates fail as a result. Maybe. Like the doctor says, well, don't do that! (i.e. use Templates and disable unicode). -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/20040903/b8ac2991/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