In email.message.py there are two import errors:
line 128 from email.Generator import Generator
should be 
  from email.generator import Generator
line 784 from email.Iterators import walk
should be 
  from email.iterators import walk

You may not like the naming applied there, but surely it is not a import
error. Can you actually manage to get an ImportError ?

Yes. If the code is used to build a standalone application with py2app 
on the Mac, here's the end of the stack trace:
  File "controller.pyo", line 17, in <module>
  File "readMail.pyo", line 15, in <module>
  File "mailbox.pyo", line 1294, in <module>
  File "email/__init__.pyo", line 79, in __getattr__
  File "email/message.pyo", line 86, in <module>
  File "email/message.pyo", line 784, in Message
  File "email/__init__.pyo", line 79, in __getattr__
ImportError: No module named iterators

Can you send a sample code that reproduces that ?

I'll put one together.

Attached is a sample code that reproduces the problem under python 2.5 on 
Mac OS 10.4.11. See file for instructions on how to reproduce the issue.

AFA I understand it the ImportError comes when running a py2exe/app'ed
package where iterators.py hasn't been included.

I was just about to file a report about (I think) the same issue, seen
on XP when py2exe'ing code using the email module.

Exactly the same problem with a good(?) explanation can be found on
http://mail.python.org/pipermail/spambayes/2007-December/021485.html

The problem comes because the real module names now are lowercase, and
email/__init__.py plays tricks with _LOWERNAMES in order to keep the old
uppercase names working. The problem is that the email lib itself uses
the old (deprecated?) non-existing name.

IMHO the solution is to use right-cased names. I have (only) tested it
by changing the single reference to email.Iterators. I think this is a
safe bugfix which should be included in 2.5 ASAP.

A workaround is to import email.iterators from some other code or to
tell py2exe/pyapp explicitly include the modules in the package.

This patch seems to fix the issue for me.

The easiest way to verify might be to create another patch and compare
them...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 25, 2008, at 10:44 AM, Mads Kiilerich wrote:

>
> Mads Kiilerich <mads@kiilerich.com> added the comment:
>
> This patch seems to fix the issue for me.
>
> The easiest way to verify might be to create another patch and compare
> them...

The patch looks pretty good, +1.  The only part I'm not so sure about  
is the renaming in test_email.py since test_email_renamed.py is  
supposed to use the new names while test_email.py (in 2.5 at least) is  
supposed to test the backward compatible names.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSBH5BnEjvBPtnXfVAQJJNAP/VEIyMvObRz9SH5EL4Tu4KuVay5C/vvxC
AvlfRrmCNJXXRdU2ZfmiSG357Zc3JfRLhxZBSVpuMQidictxUZttcnqoFlwS2Edu
VwXWtihGjMncn4qdR2IlwEUitG6eSJlrsbo+RtaDSFXlWNyzA83O3mBffeIn8vYn
FLILF8aVaQQ=
=nxt/
-----END PGP SIGNATURE-----

OK. I had assumed that backward compatibility was tested in the _renamed
tests, so that these tests one day could be dropped together with
backward compatibility. I didn't notice that my search'n'replaces showed
me that I was wrong.

But a bugfix in a stable release really shouldn't change any tests
unless the tests are wrong. And I can't come up with a reasonable new
test. It could perhaps be tested that all modules could be py2exe'ed and
imported individually with automatic dependency resolving... But such a
test doesn't belong in the test suite.

I suggest that my patch is applied without the test cleanup.

> But such a test doesn't belong in the test suite.

py2exe uses the "modulefinder" module to find dependencies.

I tried this command::

    ./python -m modulefinder Lib\email\message.py

And among the output, there is::

    ....
    ? email.Generator imported from __main__, email.message
    ? email.Iterators imported from __main__, email.message
    ....

It surely can be turned into a unit test. For example::

    import email.message
    filename = email.message.__file__
    if filename.endswith(".pyc"):
        filename = filename[:-1]

    import modulefinder
    mf=modulefinder.ModuleFinder()
    mf.run_script(filename)
    assert "email.Generator" not in mf.any_missing()

Testing that email.message doesn't use the "wrong" casing
email.Generator isn't enough. That would just test that this patch has
been applied. It must also be tested that no other modules uses the
wrong casing of email.Generator. Or other email packages. Or any other
packages at all.

IMHO the "right" test would be to test that modulefinder can find all
relevant modules in all cases. The problem is that it gives irrelevant
warnings.

I tested with some shell hacking to find all modulefinder failures which
could be found with another casing:

find * -name '*.py'|sed 's,\.py$,,g;s,/,.,g;s,\.__init__$,,g' >
/tmp/all_fs_modules
for a in $(find * -name '*.py'); do echo $a; python -m modulefinder $a;
echo; done > /tmp/all_referenced_modules
for a in $(grep ^? /tmp/all_referenced_modules|sed 's,^\? \(.*\)
imported from .*,\1,g'|sort|uniq); do grep -i "^$a"'$'
/tmp/all_fs_modules; done > /tmp/referenced_existing_ignorecased

email.base64mime
email.charset
email.encoders
email.errors
email.generator
email.header
email.iterators
email.message
email.parser
email.quoprimime
email.utils
ftplib

- where the last hit comes from bogus regexp matching. The test takes
long time to run as it is. That could probably be improved. But still I
think this is to be compared with "lint"-like tools which should be run
reguarly but isn't suitable for unit tests.

I feel ashamed for arguing against introducing a test. I think I do that
because I think that this isn't a "normal" bug and thus isn't suitable
for unit testing. 

The email module itself really is fully backwards compatible. And
modulefinder does a good job doing what it does and can't be blamed for
not figuring the email hackery out. The problem comes when a third
external modules puts things together and they doesn't fit together as
one could expect.

Also, currently both casings works and should work. Using the old casing
isn't a "bug bug", but it has consequences which IMHO is enough to call
it a bug and fix it.

Perhaps Python could have a standard way markup of deprecated functions
so that it could be checked that the standard librarary didn't use them.

I'm not sure if this is the same problem, but it seems related.  I can
get the same ImportError without involving py2exe or modulefinder:

Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import email.message
>>> sys.modules = sys.modules.copy()
>>> msg = email.message.Message()
>>> msg['From'] = 'foo@bar.com'
>>> msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/email/message.py", line 128, in as_string
    from email.Generator import Generator
  File "/usr/lib/python2.5/email/__init__.py", line 80, in __getattr__
    mod = sys.modules[self.__name__]
KeyError: 'email.generator'

If the "sys.modules = sys.modules.copy()" line is left out, everything
works as expected.

Also occurs in 2.6...

The patch looks pretty good, except that you should not change
test_email.py.  It specifically tests the old names, while
test_email_renamed.py tests the new names.

There's no point in fixing Python 2.5 since there won't be another
maintenance release of that version.  It probably also does not make
sense to change Python 3.x.  You should fix Python 2.6 though.

In the trunk, we should remove all the old names for good.

I have updated the patch. (Applied to 2.6 where it seems like some
casings had been fixed, so I dropped all the rejects. Changes to
test_email.py has been.)

Looks good; feel free to commit.

applied with r37952 (trunk), r37953 (2.6) and r37978 (py3k, docstrings 
only). Thanks for the patch!