On Fri, Oct 30, 2009 at 9:01 AM, AK Eric <span dir="ltr"><<a href="mailto:warpcat@sbcglobal.net">warpcat@sbcglobal.net</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">Should we start talking about how you can add stuff to __builtin__ and</div>
then it really is exposed to everything? (right, unless I'm missing<br>
some other Python idiom?)  Again, *not advocating* in standard<br>
practice, but I think it's important to understand how it works.<br>
(ducks incoming flak)<br></blockquote><div><br></div><div>It is important to understand how it works-- but only really in that it's important that people understand how Python handles 'finding' an object when you specify a name... not understanding this leads lots of people to various sorts of confusion, especially as they come from other languages. Python doesn't really have true nested scopes*, it doesn't search up from where you are to go 'higher' and 'higher' and then check some universal-shared global scope, etc.</div>

<div><br></div><div>Python has namespaces-- at any given time, there's only three that are accessible. The local namespace, the global namespace, and the builtin namespace.</div><div><br></div><div>When you reference 'x' in your code, say, as "y = x", Python first looks in the local namespace. Failing to find it there, it looks in the global namespace-- which is really the module-level namespace. And, finally, failing that... it looks in the builtin namespace. For, y'know, builtins.</div>

<div><br></div><div>* Okay, in Python 2.1/2.2 there was added a limited level of nested scoping to Python for functions embedded in other functions; if a name isn't found in the local scope and the local scope is a nested function, it checks the locals of the containing function too. This is a great addition, but actually seems to have inspired people to think Python has a more pervasive support of dynamic nested scoping going on-- in particular the mythical 'class scope', which it doesn't have.</div>

<div> </div><div>Now, all that said... one should NOT mess around with __builtin__. You may break third-party code you use that way, or at least introduce maintainability nightmares.</div><div><br></div><div>In Python things don't live off in the ether, everything lives in an explicit place. This is a good thing. Messing with __builtin__ and adding stuff violates this principle. It makes code harder to comprehend by just looking at a single file-- you can't know where everything is defined that way, you can't keep your mind local and 'get' what you're working on. 'from x import *' is a similar problem here, but at least there you have a flag somewhere in the file saying 'hey, go look over here to maybe find that var'.</div>

<div><br></div><div>You CAN do it, sure... and there are a some (very, very, very limited!) use-cases where its even good and the right-thing to do, which is why its exposed to you to be ABLE to do it, and doesn't have this giant 'DO NOT DO THIS!' warning in the official docs.  But unless you know you must do it to get the result you need-- then the answer to, 'Should I use this feature?' in this case is a resounding no. Use something else instead, even if it doesn't seem as 'nice' to you (such as import settings; settings.blah instead of just blah) IMHO. :)</div>

<div><br></div><div>--S</div></div>