On Mon, Feb 1, 2010 at 7:33 PM, Tim Chase <span dir="ltr"><<a href="mailto:python.list@tim.thechases.com">python.list@tim.thechases.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Stephen Hansen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First, I don't shadow built in modules. Its really not very hard to avoid.<br>
</blockquote>
<br></div>
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.  </blockquote><div><br></div>

<div>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.</div>

<div><br></div><div>"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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Although they do google around a bit to try to gauge how likely it is to clash, but still.</div><div><br></div></div><div name="mailplane_signature">--S</div>