How to guard against bugs like this one?

[Stephen Hansen]

On Mon, Feb 1, 2010 at 7:33 PM, Tim Chase <python.list 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.


I get that people run into this problem on occasion, but honestly-- its
*really* not very hard to avoid. If you're creating a module which feels..
generic. As if you may use that same name for a certain kinda topic in a
couple different programs-- chances are it /might/ be used as a generic
provider of support for that kinda topic in the standard library.

"email", "http", "url", anything with a generic .. smell. Assume it /is/ in
the stdlib until you demonstrate otherwise, if you aren't deeply familiar
with the stdlib.

And two seconds later, you can know: 'import numbers' will work. Can't use
that. Yeah, when a new version comes out, you may have to read What's New,
and see a new module, then rename something.

If you're going to use relative imports (and that's #2, I never do-- ever--
even before PEP328 existed), you just have to deal with the flatness of the
top-level namespace and how Python broadly claims the right to put darn near
anything in there.

Although they do google around a bit to try to gauge how likely it is to
clash, but still.

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100201/4edb3b14/attachment-0001.html>