Creating True Global Functions by Modifying Builtins

[Kamilche]

I really, really want a handful of 'true' global functions, ones that
can be called from anywhere without requiring importing. So I added it
to the 'builtins' of Python, and it appeared to work. :-O Will this
have unintended side-effects? :-D Take a look:

def traceme(s):
print "trace:", s

import types

def BuiltInFunctions():
callables = (types.BuiltinFunctionType, \
types.BuiltinMethodType, \
types.CodeType, types.FunctionType, \
types.GeneratorType, \
types.MethodType, \
types.UnboundMethodType)
builtins = globals()['__builtins__']
d = vars(builtins)
list = []
for name, value in d.items():
if type(value) in callables:
list.append(name)
list.sort()
return list

def AddBuiltIn(name, fn):
builtins = globals()['__builtins__']
d = vars(builtins)
if d.has_key(name):
raise Exception("Can't override built in " + \
" function " + name + "!")
d[name] = fn


print "Built in functions before adding 'trace':"
print BuiltInFunctions()
AddBuiltIn('trace', traceme)
print "Built in functions after adding 'trace':"
print BuiltInFunctions()

trace("hi there")

 

[Peter Hansen]

I really, really want a handful of 'true' global functions, ones that
can be called from anywhere without requiring importing.

No, you don't. ;-)

Really, why bother when with a simple "import kamilche_tools" (or
whatever you want), you can get access to all your stuff without
hiding it from everyone, thereby making maintenance much harder?

The only time I've found a valid reason to stick stuff in __builtin__
is when trying to make current code *forward compatible* with newer
versions of Python, such as when bool() and True/False where added
in 2.2 (?) and we had to stick with 2.0.

Any other use smells of "slick" programming and is likely to
bite you in the future.

So I added it to the 'builtins' of Python, and it appeared to work. :-O

The name __builtins__ is apparently an implementation detail.
If that's true, you don't want to use it.

Instead, if you really must, at least "import __builtin__" (note,
no "s" on the end) and use that module.

-Peter

 

[Kamilche]

No, you don't. ;-)

Yeah, I thought it was interesting when I first thought of it, but
upon reflection, I decided to use the dreaded 'from X import *'
construct instead. As long as I don't have any public global variables
in that module, I should be OK. I put a note in there to that effect,
to remind myself.

--Kamilche

 

[Andrew Clover]

The only time I've found a valid reason to stick stuff in __builtin__
is when trying to make current code *forward compatible* with newer
versions of Python, such as when bool() and True/False where added
in 2.2 (?) and we had to stick with 2.0.

Even this isn't really a good idea. Many other modules have various
different workarounds for lack of feature support, which if you are
unlucky can get confused by builtin-hacking.

Having a 'constants' module from which a package can from ... import *
is usually a better approach.

 

[Peter Hansen]

Even this isn't really a good idea. Many other modules have various
different workarounds for lack of feature support, which if you are
unlucky can get confused by builtin-hacking.

You're right in general, but what I didn't mention was that
this was code intended for an embedded system with total
control on what was present or not. It was not on code
meant for general distribution to the outside world. As
such, it served the purpose perfectly well, without any
such negatives.

> Having a 'constants' module from which a package can from ... import *
> is usually a better approach.

Quite true, in most cases.

-Peter

 

[Kamilche]

The only time I've found a valid reason to stick stuff in __builtin__
is when trying to make current code *forward compatible* with newer
versions of Python, such as when bool() and True/False where added
in 2.2 (?) and we had to stick with 2.0.

Um , that's a good idea, even in version 2.3. I don't know how many
times I've written 'true' instead of True. I think that deserves a
place in the globals file.