[mod_python] Problem with PSP and unicode

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


More information about the Mod_python mailing list