On 10/10/07, Christian Heimes <report@bugs.python.org> wrote:
>
> Christian Heimes added the comment:
>
> Guido van Rossum wrote:
> > Did you svn up, make clean and rebuild?
>
> The ctypes package didn't change since my last rebuild an hour ago. I'm
> on Linux (Ubuntu i386)

Odd. I'll investigate when I have more time.

> >> test_email: need some help from an email expoert
> >
> > Which test is failing?
>
> test_decoded_generator()
> The generator tries to print a str8 to a text file.

Thought so. I have a tentative fix that I want approved by Barry
Warsaw before checking; you can see if it works for you too:

--- Lib/email/generator.py      (revision 58412)
+++ Lib/email/generator.py      (working copy)
@@ -288,7 +288,7 @@
         for part in msg.walk():
             maintype = part.get_content_maintype()
             if maintype == 'text':
-                print(part.get_payload(decode=True), file=self)
+                print(part.get_payload(decode=False), file=self)
             elif maintype == 'multipart':
                 # Just skip this
                 pass

> > Yes, __file__ always has that type. Fixing it is messy because it
> > requires using the default filesystem encoding. Can you try that as a
> > separate patch?
>
> I'm already working on it. Can I introduce a new function
> _PyUnicode_AsDefaultFSEncodedString that encodes unicode using
> Py_FileSystemDefaultEncoding or UTF-8?

That's a rather long name... I don't think it needs a leading
underscore. How about

PyUnicode_AsFSString()?