On Mon, Feb 1, 2010 at 7:33 PM, Tim Chase <python.l...@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
-- http://mail.python.org/mailman/listinfo/python-list