Home Original page

abusing __builtins__

Tim Peters tim.one at home.com
Mon Feb 26 01:36:47 EST 2001 
[Tim]
>> The language may someday make "GlobalVariable" the name of its
>> own builtin,> and then your code won't work correctly if you
>> either try to use the new builtin or call any other module that
>> does (incl. without limitation std library modules).

[Vassilis Virvilis]
> This I don't get it. Why is that?

I think because you're reading it the opposite of the way it's written
<wink>:  I'm not saying you can't get at *your* meaning of the name anymore,
but that the *new* meaning gets masked (because you've overwritten it).

> ...
> Consider the following imaginary example. In a project where there is no
> need to open files one replaces the open function. So this project will
> never manage to open a file but aside from that it will continue to work
> as designed.

Very dangerous.  It's virtually impossible to write a substantial Python
program without invoking at least some of the std libraries.  And you simply
can't know whether *those* will use "open" across releases.  If they do,
they certainly aren't expecting to get *your* meaning of the name, they're
expecting the builtin meaning.

There are uses for that, though.  For example, on rare occasions and for
debugging purposes, I've replaced the builtin open with my own version that
logs the name of the file being opened along with a timestamp.  In that
case, it's "a feature" that the std libraries also see my redefined version.
That was a lifesaver at least once, and it's way cool that Python let me get
away with it.  It's never meant to be a permanent thing, though.

That's OK by Python:  it generally supports all the sickness you can inflict
on yourself, provided only that you agree in advance that you're in a state
of sin and won't complain if you're later condemned for it <wink>.

guido-makes-a-nice-living-selling-indulgences-on-the-side-ly y'rs  - tim
More information about the Python-list mailing list