homepage

Try this to reproduce error:
$ mkdir -p test/email
$ cd test
$ touch __init__.py email/__init__.py
$ cat <<! > foo.py
from __future__ import absolute_import
import smtplib
!
$ python
>>> import foo
...
 File "/usr/lib/python2.6/smtplib.py", line 46, in <module>
 import email.utils
ImportError: No module named utils
If you rename the email subdirectory, it will find email.utils where it
should find it.
Strangely, this doesn't happen if you have an 'os' subdirectory and try
to import shlex, which does: import os.path ??

Running the interactive interpreter like that places the current
directory on sys.path, so it *is* doing an absolute import of your
pseudo email package. (If it didn't do that, your test would fail at the
"import foo" line)
Instead of cd'ing into test the way you did, invoke the interpreter from
the next directory up and do an import of 'test.foo', and you should see
the absolute imports in the foo module having the desired effect.
(I expect the reason you didn't run into this for the os module is
because the os module is bootstrapped quite early in Python's startup
process, so you'd have to try really hard to get it to see something
other than the builtin standard library version of os)

OK, I see where I mis-diagnosed the problem. It seems that importing
smtplib (for example) shouldn't get confused with my email package. As
I understand it, using relative imports within a package should avoid
the problem of the names of subordinate packages/modules colliding with
those in other packages. Should the problem have been written up that
the standard modules (e.g., smtplib) should use relative imports to
avoid name collision problems like this? (I'm not sure if relative
imports work for standard modules).
If this is the correct statement of the problem, I can resubmit it if
that's easier.
Thanks in advance!

Using relative imports within smtplib wouldn't have made any difference
in this case. Your dummy email package was the first one encountered on
sys.path, so the "import email.smtplib" line (which does an "import
email" internally as the first step in resolving the import, and then
tries to find "smtplib" in email.__path__) picked it up.
Putting an internal package directory on sys.path (as your example does)
is seriously bad ju-ju. It's one of the main reason why people are so
strongly discouraged from directly executing files that are stored in
package directories (along with another nasty side effect in getting two
different copies of the same module using different names, it also has
the same effect as what you did here - subpackages/modules can end up
overriding standard library modules and packages because the script
directory gets placed on sys.path).