apt.shansen at gmail
Oct 30, 2009, 9:46 AM
Post #18 of 20
(668 views)
Permalink
|
On Fri, Oct 30, 2009 at 9:01 AM, AK Eric <warpcat [at] sbcglobal> wrote:
> Should we start talking about how you can add stuff to __builtin__ and
> then it really is exposed to everything? (right, unless I'm missing
> some other Python idiom?) Again, *not advocating* in standard
> practice, but I think it's important to understand how it works.
> (ducks incoming flak)
>
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.
Python has namespaces-- at any given time, there's only three that are
accessible. The local namespace, the global namespace, and the builtin
namespace.
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.
* 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.
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.
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'.
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. :)
--S
|
