From barry at python.org Mon Feb 6 04:53:49 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 05 Feb 2006 22:53:49 -0500 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 Message-ID: <1139198029.7246.9.camel@geddy.wooz.org> Mark Sapiro submitted SF bug #1409455 against email 2.5. https://sourceforge.net/tracker/index.php?func=detail&aid=1409455&group_id=5470&atid=105470 Mark attached an example program and a candidate patch. I've uploaded an alternative patch which encodes the payload immediately during the Message.set_payload() call when a charset is given. The patch also changes Generator.py to not doubly encode the payload. This change passes Mark's example, and passes all the existing unit tests except one. But I think that test is actually wrong so the patch fixes that too (and adds a test for .get_payload(decode=True)). Before I commit this I'd like to get some feedback. I haven't looked closely but I suspect that email 3.0 should similarly change. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060205/a2d3fe00/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Mon Feb 6 22:16:27 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 07 Feb 2006 06:16:27 +0900 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <1139198029.7246.9.camel@geddy.wooz.org> References: <1139198029.7246.9.camel@geddy.wooz.org> Message-ID: <43E7BCAB.6020805@is.kochi-u.ac.jp> Barry Warsaw wrote: > Mark Sapiro submitted SF bug #1409455 against email 2.5. > > https://sourceforge.net/tracker/index.php?func=detail&aid=1409455&group_id=5470&atid=105470 Hi, I am now testing the patch but it looks like it breaks some of japanese mail encoding rules, input/output charset conversion. I want to look at it closer but it may take some time because I'm busy this and next weeks on my students. :-( > > Mark attached an example program and a candidate patch. I've uploaded > an alternative patch which encodes the payload immediately during the > Message.set_payload() call when a charset is given. The patch also > changes Generator.py to not doubly encode the payload. > > This change passes Mark's example, and passes all the existing unit > tests except one. But I think that test is actually wrong so the patch > fixes that too (and adds a test for .get_payload(decode=True)). > > Before I commit this I'd like to get some feedback. I haven't looked > closely but I suspect that email 3.0 should similarly change. > > -Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Email-SIG mailing list > Email-SIG at python.org > Your options: http://mail.python.org/mailman/options/email-sig/tkikuchi%40is.kochi-u.ac.jp -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Tue Feb 7 02:18:58 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 07 Feb 2006 10:18:58 +0900 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <43E7BCAB.6020805@is.kochi-u.ac.jp> References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> Message-ID: <43E7F582.1090604@is.kochi-u.ac.jp> Hi again Barry, Tokio Kikuchi wrote: > Barry Warsaw wrote: > >>Mark Sapiro submitted SF bug #1409455 against email 2.5. >> >>https://sourceforge.net/tracker/index.php?func=detail&aid=1409455&group_id=5470&atid=105470 > > > Hi, I am now testing the patch but it looks like it breaks some of > japanese mail encoding rules, input/output charset conversion. > > I want to look at it closer but it may take some time because I'm busy > this and next weeks on my students. :-( > This patch (in addition to the SF uploaded one) should be OK. --- /home/mailman/src/sf/mailman-2.1/misc/email-2.5.6/email/Message.py Tue Feb 7 10:12:53 2006 +++ Message.py Tue Feb 7 09:55:55 2006 @@ -272,6 +272,8 @@ charset=charset.get_output_charset()) else: self.set_param('charset', charset.get_output_charset()) + if str(charset) <> charset.get_output_charset(): + self._payload = charset.body_encode(self._payload) if not self.has_key('Content-Transfer-Encoding'): cte = charset.get_body_encoding() if callable(cte): Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Tue Feb 7 05:58:03 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 6 Feb 2006 23:58:03 -0500 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <43E7F582.1090604@is.kochi-u.ac.jp> References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> <43E7F582.1090604@is.kochi-u.ac.jp> Message-ID: On Feb 6, 2006, at 8:18 PM, Tokio Kikuchi wrote: > Hi again Barry, > > Tokio Kikuchi wrote: >> Barry Warsaw wrote: >>> Mark Sapiro submitted SF bug #1409455 against email 2.5. >>> >>> https://sourceforge.net/tracker/index.php? >>> func=detail&aid=1409455&group_id=5470&atid=105470 >> Hi, I am now testing the patch but it looks like it breaks some of >> japanese mail encoding rules, input/output charset conversion. >> I want to look at it closer but it may take some time because I'm >> busy >> this and next weeks on my students. :-( > > This patch (in addition to the SF uploaded one) should be OK. > > --- /home/mailman/src/sf/mailman-2.1/misc/email-2.5.6/email/ > Message.py Tue Feb 7 10:12:53 2006 > +++ Message.py Tue Feb 7 09:55:55 2006 > @@ -272,6 +272,8 @@ > charset=charset.get_output_charset()) > else: > self.set_param('charset', charset.get_output_charset()) > + if str(charset) <> charset.get_output_charset(): > + self._payload = charset.body_encode(self._payload) > if not self.has_key('Content-Transfer-Encoding'): > cte = charset.get_body_encoding() > if callable(cte): Hi Tokio, Thanks! Do you have a test case for this patch? If there are no objections, I'm going to apply these to 2.5.7 and 3.0. -Barry From msapiro at value.net Tue Feb 7 06:30:31 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 6 Feb 2006 21:30:31 -0800 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: Message-ID: Barry Warsaw wrote: >On Feb 6, 2006, at 8:18 PM, Tokio Kikuchi wrote: >> >> This patch (in addition to the SF uploaded one) should be OK. >> >> --- /home/mailman/src/sf/mailman-2.1/misc/email-2.5.6/email/ >> Message.py Tue Feb 7 10:12:53 2006 >> +++ Message.py Tue Feb 7 09:55:55 2006 >> @@ -272,6 +272,8 @@ >> charset=charset.get_output_charset()) >> else: >> self.set_param('charset', charset.get_output_charset()) >> + if str(charset) <> charset.get_output_charset(): >> + self._payload = charset.body_encode(self._payload) >> if not self.has_key('Content-Transfer-Encoding'): >> cte = charset.get_body_encoding() >> if callable(cte): > >Hi Tokio, > >Thanks! Do you have a test case for this patch? I've tested my test cases with Tokio's patch and they (still) work. But, they worked without Tokio's addition so that doesn't say much. Looking at the code, I think a test case would need to have an initial character encoding of 'euc-jp' or 'shift_jis' to see the problem that Tokio is fixing. >If there are no objections, I'm going to apply these to 2.5.7 and 3.0. I don't object. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From tkikuchi at is.kochi-u.ac.jp Wed Feb 8 00:51:50 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 08 Feb 2006 08:51:50 +0900 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> <43E7F582.1090604@is.kochi-u.ac.jp> Message-ID: <43E93296.3060805@is.kochi-u.ac.jp> Barry Warsaw wrote: > On Feb 6, 2006, at 8:18 PM, Tokio Kikuchi wrote: > >> Hi again Barry, >> >> Tokio Kikuchi wrote: >> >>> Barry Warsaw wrote: >>> >>>> Mark Sapiro submitted SF bug #1409455 against email 2.5. >>>> >>>> https://sourceforge.net/tracker/index.php? >>>> func=detail&aid=1409455&group_id=5470&atid=105470 >>> >>> Hi, I am now testing the patch but it looks like it breaks some of >>> japanese mail encoding rules, input/output charset conversion. >>> I want to look at it closer but it may take some time because I'm busy >>> this and next weeks on my students. :-( >> >> >> This patch (in addition to the SF uploaded one) should be OK. >> >> --- /home/mailman/src/sf/mailman-2.1/misc/email-2.5.6/email/ >> Message.py Tue Feb 7 10:12:53 2006 >> +++ Message.py Tue Feb 7 09:55:55 2006 >> @@ -272,6 +272,8 @@ >> charset=charset.get_output_charset()) >> else: >> self.set_param('charset', charset.get_output_charset()) >> + if str(charset) <> charset.get_output_charset(): >> + self._payload = charset.body_encode(self._payload) >> if not self.has_key('Content-Transfer-Encoding'): >> cte = charset.get_body_encoding() >> if callable(cte): > > > Hi Tokio, > > Thanks! Do you have a test case for this patch? I've tested with mailman sending attachment email. A script like this should be useful in testing the japanese spacial problem. % cat testja.py jhello = '\xa5\xcf\xa5\xed\xa1\xbc\xa5\xef\xa1\xbc\xa5\xeb\xa5\xc9\xa1\xaa' jcode = 'euc-jp' print jhello import email.Message m = email.Message.Message() m.set_payload(jhello, jcode) u = unicode(m.get_payload(), m.get_content_charset()) if jhello <> u.encode(jcode): raise print u.encode(jcode) > > If there are no objections, I'm going to apply these to 2.5.7 and 3.0. > > -Barry > > > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Wed Feb 8 01:18:54 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 08 Feb 2006 09:18:54 +0900 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <43E93296.3060805@is.kochi-u.ac.jp> References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> <43E7F582.1090604@is.kochi-u.ac.jp> <43E93296.3060805@is.kochi-u.ac.jp> Message-ID: <43E938EE.7060900@is.kochi-u.ac.jp> > > >>If there are no objections, I'm going to apply these to 2.5.7 and 3.0. >> I've added a note on the Charset.py CODEC_MAP SF#1409538. It looks like we need japanese charsets entry here without 'japanese' prefix. Sorry but I have not enough time to generate new patch. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Wed Feb 8 04:10:31 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 07 Feb 2006 22:10:31 -0500 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <43E938EE.7060900@is.kochi-u.ac.jp> References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> <43E7F582.1090604@is.kochi-u.ac.jp> <43E93296.3060805@is.kochi-u.ac.jp> <43E938EE.7060900@is.kochi-u.ac.jp> Message-ID: <1139368231.19968.24.camel@geddy.wooz.org> On Wed, 2006-02-08 at 09:18 +0900, Tokio Kikuchi wrote: > > > > > >>If there are no objections, I'm going to apply these to 2.5.7 and 3.0. > >> > > I've added a note on the Charset.py CODEC_MAP SF#1409538. > It looks like we need japanese charsets entry here without 'japanese' > prefix. > > Sorry but I have not enough time to generate new patch. No problem. See the patch attached to SF #1409538, which should address both this and SF #1409544, and incorporates your testja.py test case. https://sourceforge.net/tracker/index.php?func=detail&aid=1409538&group_id=5470&atid=105470 This passes with 214 tests on Python 2.1 through 2.3 with no third party codecs, and 216 tests on Python 2.4 and 2.5 with the built-in codecs. Please let me know what you think -- if it looks good, I'll apply it to all email package versions and close both issues. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060207/6f629a13/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Wed Feb 8 13:56:54 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 08 Feb 2006 21:56:54 +0900 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <1139368231.19968.24.camel@geddy.wooz.org> References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> <43E7F582.1090604@is.kochi-u.ac.jp> <43E93296.3060805@is.kochi-u.ac.jp> <43E938EE.7060900@is.kochi-u.ac.jp> <1139368231.19968.24.camel@geddy.wooz.org> Message-ID: <43E9EA96.9080002@is.kochi-u.ac.jp> Barry Warsaw wrote: > On Wed, 2006-02-08 at 09:18 +0900, Tokio Kikuchi wrote: > >>> >>>>If there are no objections, I'm going to apply these to 2.5.7 and 3.0. >>>> >> >>I've added a note on the Charset.py CODEC_MAP SF#1409538. >>It looks like we need japanese charsets entry here without 'japanese' >>prefix. >> >>Sorry but I have not enough time to generate new patch. > > > No problem. See the patch attached to SF #1409538, which should address > both this and SF #1409544, and incorporates your testja.py test case. > > https://sourceforge.net/tracker/index.php?func=detail&aid=1409538&group_id=5470&atid=105470 > > This passes with 214 tests on Python 2.1 through 2.3 with no third party > codecs, and 216 tests on Python 2.4 and 2.5 with the built-in codecs. > Please let me know what you think -- if it looks good, I'll apply it to > all email package versions and close both issues. It is perfect! Thank you! -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Wed Feb 8 14:36:07 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 08 Feb 2006 08:36:07 -0500 Subject: [Email-SIG] set_payload() -- SF bug # 1409455 In-Reply-To: <43E9EA96.9080002@is.kochi-u.ac.jp> References: <1139198029.7246.9.camel@geddy.wooz.org> <43E7BCAB.6020805@is.kochi-u.ac.jp> <43E7F582.1090604@is.kochi-u.ac.jp> <43E93296.3060805@is.kochi-u.ac.jp> <43E938EE.7060900@is.kochi-u.ac.jp> <1139368231.19968.24.camel@geddy.wooz.org> <43E9EA96.9080002@is.kochi-u.ac.jp> Message-ID: <1139405767.19968.34.camel@geddy.wooz.org> On Wed, 2006-02-08 at 21:56 +0900, Tokio Kikuchi wrote: > It is perfect! Thank you! Thanks! It's apply to email 2.5 now (r42270). I'll try to port it to email 3.0 later today. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060208/ed72813f/attachment.pgp From barry at python.org Wed Feb 8 20:47:02 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 08 Feb 2006 14:47:02 -0500 Subject: [Email-SIG] PEP 8 module names for email 3.1? Message-ID: <1139428022.15736.33.camel@geddy.wooz.org> For a while now, I've been wanting to migrate the email package to PEP 8 modules names. With Python 2.5 we have an opportunity to do this, while bumping the email package version number to 3.1. We'd have to do this in a backward compatible way of course, for at least one Python release. Most new names would map pretty obviously, just by lowercasing them. For example email.Charset would become email.charset and email.FeedParser would become email.feedparser. I'd like to do something differently for the MIME* modules. For those, I'm thinking about creating an email.mime subpackage and populating that with the package names, sans the 'MIME' prefix. So email.MIMEMultipart would become email.mime.multipart and email.NonMultipart would become email.mime.nonmultipart. As per PEP 8, none of the class names inside those modules would need to change. So first the question is whether anyone else would like to see this. If the answer to that is "yes", then the next question is, what's the best way to accomplish this while retaining the existing API for backward compatibility? We can't just include both the legacy and lowercase Python files in the same directory, because on case-insensitive file systems they'd actually /be/ the same files. I'm not sure if we can play sufficient import hook hacks to make it work, and I'm uncomfortable with just importing everything in the __init__.py and playing mapping games in sys.modules. So if you'd like to see this happen, do you have suggestions for efficiently doing the mapping? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060208/0e712bd2/attachment.pgp From t-meyer at ihug.co.nz Wed Feb 8 20:53:58 2006 From: t-meyer at ihug.co.nz (Tony Meyer) Date: Thu, 9 Feb 2006 08:53:58 +1300 Subject: [Email-SIG] PEP 8 module names for email 3.1? In-Reply-To: <1139428022.15736.33.camel@geddy.wooz.org> References: <1139428022.15736.33.camel@geddy.wooz.org> Message-ID: <5F52C4C8-5511-4337-A4F0-A9BFD39AF569@ihug.co.nz> > For a while now, I've been wanting to migrate the email package to > PEP 8 > modules names. With Python 2.5 we have an opportunity to do this, > while > bumping the email package version number to 3.1. We'd have to do this > in a backward compatible way of course, for at least one Python > release. > [...] > So first the question is whether anyone else would like to see this. +1 here. > So if you'd like to see this happen, do you have suggestions for > efficiently doing the mapping? Unfortunately not, but I'm sure I'll be +1 on whatever the smart people come up with :) =Tony.Meyer From fdrake at acm.org Wed Feb 8 22:49:43 2006 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 8 Feb 2006 16:49:43 -0500 Subject: [Email-SIG] PEP 8 module names for email 3.1? In-Reply-To: <1139428022.15736.33.camel@geddy.wooz.org> References: <1139428022.15736.33.camel@geddy.wooz.org> Message-ID: <200602081649.43235.fdrake@acm.org> On Wednesday 08 February 2006 14:47, Barry Warsaw wrote: > So first the question is whether anyone else would like to see this. +1 > If > the answer to that is "yes", then the next question is, what's the best > way to accomplish this while retaining the existing API for backward > compatibility? This is a clear case for lazy imports; perhaps something like this in email/__init__.py: import sys class LazyImporter(object): def __init__(self, module_name): self.__module_name = module_name def __getattr__(self, name): __import__(self.__module_name) mod = sys.modules[self.__module_name] self.__dict__.update(mod.__dict__) return getattr(mod, name) sys.modules["email.MIMEText"] = LazyImporter("email.mime.text") ... -Fred -- Fred L. Drake, Jr. From barry at python.org Thu Feb 9 03:52:28 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 08 Feb 2006 21:52:28 -0500 Subject: [Email-SIG] PEP 8 module names for email 3.1? In-Reply-To: <200602081649.43235.fdrake@acm.org> References: <1139428022.15736.33.camel@geddy.wooz.org> <200602081649.43235.fdrake@acm.org> Message-ID: <1139453548.10366.5.camel@geddy.wooz.org> On Wed, 2006-02-08 at 16:49 -0500, Fred L. Drake, Jr. wrote: > This is a clear case for lazy imports; perhaps something like this in > email/__init__.py: > > import sys > > class LazyImporter(object): > def __init__(self, module_name): > self.__module_name = module_name > > def __getattr__(self, name): > __import__(self.__module_name) > mod = sys.modules[self.__module_name] > self.__dict__.update(mod.__dict__) > return getattr(mod, name) > > sys.modules["email.MIMEText"] = LazyImporter("email.mime.text") > ... That's a great start Fred, thanks! I've now got a copy of the email package that supports both naming schemes. I've also got two copies of the test modules, one that tests the old names and one that tests the new names. The only change necessary in the old name tests was the __all__ test (which makes sense of course). So, rather than post patches or commit this to the Python trunk, I'm going to make a copy in the sandbox and check the changes in there. It would be great if people could check it out and let me know what you think. I'll send an email when that's done. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060208/0ac4dcd1/attachment.pgp From barry at python.org Thu Feb 9 04:09:49 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 08 Feb 2006 22:09:49 -0500 Subject: [Email-SIG] PEP 8 module names for email 3.1? In-Reply-To: <1139453548.10366.5.camel@geddy.wooz.org> References: <1139428022.15736.33.camel@geddy.wooz.org> <200602081649.43235.fdrake@acm.org> <1139453548.10366.5.camel@geddy.wooz.org> Message-ID: <1139454589.10366.8.camel@geddy.wooz.org> On Wed, 2006-02-08 at 21:52 -0500, Barry Warsaw wrote: > So, rather than post patches or commit this to the Python trunk, I'm > going to make a copy in the sandbox and check the changes in there. It > would be great if people could check it out and let me know what you > think. > > I'll send an email when that's done. http://svn.python.org/projects/sandbox/trunk/emailpkg/3.1/ I'm going to post a message to python-dev, but let's keep the discussion here. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060208/7d7d0fdf/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Sun Feb 12 01:38:55 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 12 Feb 2006 09:38:55 +0900 Subject: [Email-SIG] PEP 8 module names for email 3.1? In-Reply-To: <1139454589.10366.8.camel@geddy.wooz.org> References: <1139428022.15736.33.camel@geddy.wooz.org> <200602081649.43235.fdrake@acm.org> <1139453548.10366.5.camel@geddy.wooz.org> <1139454589.10366.8.camel@geddy.wooz.org> Message-ID: <43EE839F.3050700@is.kochi-u.ac.jp> Barry Warsaw wrote: > > http://svn.python.org/projects/sandbox/trunk/emailpkg/3.1/ > > I'm going to post a message to python-dev, but let's keep the discussion > here. Hi, I had a short time importing this code into my mailman-2.2 test code. It looks like we need adding 'email.mime' into the packages list. url='http://www.python.org/sigs/email-sig', packages=['email', 'email.mime'], ) Another problem was that charset was stored in unicode and doesn't fit into current mailman code. A sample test code below illustrates this problem: $ cat testcset.py import email.Message import email.Charset m = email.Message.Message() m.set_payload('Hello!\n', 'us-ascii') charset = m.get_content_charset() if type(charset) <> type(email.Charset.Charset()): charset = email.Charset.Charset(charset) print type(charset) $ python testcset.py Traceback (most recent call last): File "testcset.py", line 8, in ? charset = email.Charset.Charset(charset) File "/home/tkikuchi/work/email/3.1/email/charset.py", line 190, in __init__ input_charset = unicode(input_charset, 'ascii').lower() TypeError: decoding Unicode is not supported This is fixed by this patch: $ diff -u charset.py.orig charset.py --- charset.py.orig 2006-02-12 09:01:14.374411200 +0900 +++ charset.py 2006-02-12 09:03:18.663129600 +0900 @@ -187,7 +187,7 @@ def __init__(self, input_charset=DEFAULT_CHARSET): # RFC 2046, $4.1.2 says charsets are not case sensitive. We coerce to # unicode because its .lower() is locale insensitive. - input_charset = unicode(input_charset, 'ascii').lower() + input_charset = unicode(input_charset, 'ascii').lower().encode('ascii') # Set the input charset after filtering through the aliases self.input_charset = ALIASES.get(input_charset, input_charset) # We can try to guess which encoding and conversion to use by the But, I don't know if this is the right fix. A charset should be written in ASCII only and I don't know if there is a locale dependent lower() function which fails to lower the ASCII characters. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Tue Feb 21 04:01:02 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 20 Feb 2006 22:01:02 -0500 Subject: [Email-SIG] PEP 8 module names for email 3.1? In-Reply-To: <43EE839F.3050700@is.kochi-u.ac.jp> References: <1139428022.15736.33.camel@geddy.wooz.org> <200602081649.43235.fdrake@acm.org> <1139453548.10366.5.camel@geddy.wooz.org> <1139454589.10366.8.camel@geddy.wooz.org> <43EE839F.3050700@is.kochi-u.ac.jp> Message-ID: <1140490862.17666.56.camel@geddy.wooz.org> On Sun, 2006-02-12 at 09:38 +0900, Tokio Kikuchi wrote: > It looks like we need adding 'email.mime' into the packages list. > > url='http://www.python.org/sigs/email-sig', > packages=['email', 'email.mime'], > ) > > Another problem was that charset was stored in unicode and doesn't fit > into current mailman code. A sample test code below illustrates this > problem: I have fixes for both these about to go in. I've also decided that the module name changes warrant a bump in the version number to 4.0. I'm removing 4 previously deprecated methods and updating all the documentation. Watch the commit messages momentarily. I'll probably do a separate beta release soon and then we'll be merging this into the Python 2.5 trunk. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/email-sig/attachments/20060220/df511130/attachment.pgp