Early binding as an option
alain at dpt-info.u-strasbg.fr
Tue Aug 2 15:02:31 EDT 2011
Chris Angelico <rosuav at gmail.com> writes:
> As I understand it, Python exclusively late-binds names; when you
> define a function, nothing is ever pre-bound. This allows a huge
> amount of flexibility (letting you "reach into" someone else's
> function and change its behaviour), but it's flexibility that most
> programs use seldom if at all.
I agree with you on your last remark, but unfortunately it's part of the
language. Therefore, there *are* programs that rely on the ability to
rebind 'let' and others. Changing this would require changing the
language, basically turning some builtins into keywords.
(BTW, the dynamic binding also has implications for security.)
> Argument in favour: Efficiency is also a Good Thing, and with staples
> like 'len', it's unlikely anyone will want to change them - yet the
> interpreter still has to do a namespace lookup every time.
Yes, and it can't do common subexpression elimination, code hoisting,
etc. Basically, nothing can be optimized, and the interpreter has to
execute bytecode that exactly represents source code.
> I would want the end programmer to have the ultimate power here (not
> the module designer). Something along the lines of: This global name
> will never change, so don't bother looking it up every time.
Maybe some module could provide specialized, "use-at-your-own-risk"
versions of some functions/operators. An example is '+' which can mean
so many things that any use of it probably spends more time finding the
right version than actually doing the work.
The problem with such pre-bound identifiers is that anybody with
performance problems would start peppering his/her code with things like
plus_float_float(x,y), leading to unreadable code, to all kinds of
strange errors, etc. Nobody really wants this probably.
> Is this the realm of JIT compilation, or can it be done in regular
No, it's a matter of language definition. A JIT can't do much here
(actually jitting is almost orthogonal to that question), at least it
couldn't do much better than CPython. It just has to go through all the
lookups. IIRC, unladden-swallow has tried the JIT route, using LLVM as
the backend. It seems they gave up.
More information about the Python-list