How to guard against bugs like this one?

[Carl Banks]

On Feb 1, 7:33 pm, Tim Chase <python.l... at tim.thechases.com> wrote:
> Stephen Hansen wrote:
> > First, I don't shadow built in modules. Its really not very hard to avoid.
>
> Given the comprehensive nature of the batteries-included in
> Python, it's not as hard to accidentally shadow a built-in,
> unknown to you, but yet that is imported by a module you are
> using.  The classic that's stung me enough times (and many others
> on c.l.p and other forums, as a quick google evidences) such that
> I *finally* remember:
>
>    bash$ touch email.py
>    bash$ python
>    ...
>    >>> import smtplib
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>      File "/usr/lib/python2.5/smtplib.py", line 46, in <module>
>        import email.Utils
>    ImportError: No module named Utils
>
> Using "email.py" is an innocuous name for a script/module you
> might want to do emailish things, and it's likely you'll use
> smtplib in the same code...and kablooie, things blow up even if
> your code doesn't reference or directly use the built-in email.py.


email.py is not an innocuous name, it's a generic name in a global
namespace, which is a Bad Thing.  Plus what does a script or module
called "email.py" actually do?  Send email?  Parse email?  "email" is
terrible name for a module and you deserve what you got for using it.

Name your modules "send_email.py" or "sort_email.py" or if it's a
library module of related functions, "email_handling.py".  Modules and
scripts do things (usually), they should be given action words as
names.


(**) Questionable though it be, if the Standard Library wants to use
an "innocuous" name, It can.


Carl Banks