homepage

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()?