A recent update to the trunk contains an important improvement to
g.pr, and thus g.trace, which uses g.pr.
g.pr now calls::
s = g.toEncodedString(s,sys.stdout.encoding)
just before calling sys.stdout.write This, apparently, makes the call
to sys.stdout.write *exactly* equivalent to Python's print statement.
This is important, for several reasons:
1. Previously, "print s" handled unicode characters properly in cases
where "sys.stdout.write(s)" did not.
2. In the (presumably long) transition from Python 2.x to Python 3.x,
it is *not possible* to use use Python's print statement in g.pr,
because the syntax "print s," is not valid in Python 3.x.
3. Making g.trace work properly eliminates a lot of confusion during
testing. The latest instance was while tracking down the aspell
unicode bug. g.trace wasn't showing relevé properly, even though it
was a normal unicode string.
BTW, on my machine sys.stdout.encoding was one of the cp encodings,
even though my sitecustomize.py sets Python's default encoding to
utf-8. It was quite a surprise, and resolves a *long* standing
mystery.
Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
