Dan Eloff
dan.eloff at gmail.com
Tue Feb 14 13:46:37 EST 2006
That's the sticky part, currently this doesn't work in python. Quoting one of the PEPs: One notable difficulty arises when code requires a string representation of an object; an operation traditionally accomplished by using the str() built-in function. Using the current str() function makes the code not Unicode-safe. Replacing a str() call with a unicode() call makes the code not str-stable. Changing str() so that it could return unicode instances would solve this problem. That's all well and good, but until/if that is ever adopted, we'll have to find a way around it. Probably your best bet for backwards compatibility and unicode support is to have two kinds of psp pages, one for plain ascii, one for unicode. The unicode one uses unicode() and the ascii one stays as is. You would then have to decide when you parse the psp page what the encoding is and produce the appropriate psp object. -Dan On 2/14/06, Gregory (Grisha) Trubetskoy <grisha at modpython.org> wrote: > > > I'm a bit unicode-ignorant - what should PSP do? The idea was that a > variable referred to in a PSP page would be an object that could stringify > itself by implementing a __str__(), but obviously this doesn't work with > unicode at all. But I'm not sure how self-representation works in the > unicode world... > > Grisha > > On Mon, 13 Feb 2006, Dan Eloff wrote: > > > Actually I was just about to post a question about this. The psp > generated > code surrounds everything with str() before writing it, so it doesn't work > with unicode at all. > > -Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20060214/9c9cca9b/attachment.html
|