How to guard against bugs like this one?

Jean-Michel Pichavant jeanmichel at
Tue Feb 2 11:49:04 CET 2010

Carl Banks wrote:
> On Feb 1, 7:33 pm, Tim Chase <python.l... at> 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
>>    bash$ python
>>    ...
>>    >>> import smtplib
>>    Traceback (most recent call last):
>>      File "<stdin>", line 1, in <module>
>>      File "/usr/lib/python2.5/", line 46, in <module>
>>        import email.Utils
>>    ImportError: No module named Utils
>> Using "" 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
> 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 "" 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 "" or "" or if it's a
> library module of related functions, "".  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
That does not solve anything, if the smtplib follows your advice, then 
you'll be shadowing its send_email module.
The only way to avoid collision would be to name your module

That way, the probabilty you'd shadow one package hidden module is below 
the probability that Misses Hilton ever says something relevant.
However nobody wants to use such names.

Stephen gave good advices in this thread that helps avoiding this issue.


More information about the Python-list mailing list