[Python-Dev] Possible optimization for LOAD_FAST ?

Nick Coghlan ncoghlan at gmail.com
Tue Jan 4 17:03:35 CET 2011


On Tue, Jan 4, 2011 at 8:49 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> I think someone else pointed this out, but replacing builtins externally to
> a module is actually common for testing. In particular replacing the open
> function, but also other builtins, is often done temporarily to replace it
> with a mock. It seems like this optimisation would break those tests.

print() and input() come to mind. However, so long as appropriate
tools are provided to recompile a module with this optimisation
disabled for certain builtins (with some builtins such as open(),
print() and input() blacklisted by default) then that issue should be
manageable.

I've extracted the full list of 68 builtin functions from the table in
the docs below. I've placed asterisks next to the ones I think we
would *want* to be eligible for optimisation. Aside from the 3
mentioned above, we could fairly easily omit ones which are used
primarily at the interactive prompt (i.e. dir(), help()), as well as
__import__() (since that lookup is handled specially anyway).

Cheers,
Nick.

__import__()
abs() *
all() *
any() *
ascii() *
bin() *
bool() *
bytearray() *
bytes() *
callable() *
chr() *
classmethod() *
compile() *
complex() *
delattr() *
dict() *
dir()
divmod() *
enumerate() *
eval() *
exec() *
filter() *
float() *
format() *
frozenset() *
getattr() *
globals() *
hasattr() *
hash() *
help()
hex() *
id() *
input()
int() *
isinstance() *
issubclass() *
iter() *
len() *
list() *
locals() *
map() *
max() *
memoryview() *
min() *
next() *
object() *
oct() *
open()
ord() *
pow() *
print()
property() *
range() *
repr() *
reversed() *
round() *
set() *
setattr() *
slice() *
sorted() *
staticmethod() *
str() *
sum() *
super() *
tuple() *
type() *
vars() *
zip() *


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list