Early binding as an option

Teemu Likonen tlikonen at iki.fi
Tue Aug 2 21:12:26 CEST 2011


* 2011-08-02T11:03:24-07:00 * Chris Rebert wrote:

> Smart enough JITers can infer that late binding is not being exploited
> for certain variables and thus optimize them accordingly. Look how
> fast some of the JavaScript VMs are, despite JavaScript also being
> highly dynamic.

Or Common Lisp. It has "packages" (namespaces for symbols). All the
standard symbols are in the COMMON-LISP (CL) package which is locked and
can't be modified. When the Lisp reader is parsing the source code
character stream it knows which package symbols belong to. So, for
example, at compile time there is the information that symbol + refers
to the standard CL:+ add function. There's no need to be smart.

The CL package is static and set to stone but programmer is free to
control symbols in other packages. For example, in some other package
programmer can import all symbols from the standard CL package except
shadow the CL:+ symbol. Then she can write her own extended version of +
function (which possibly falls back to CL:+ in some situations). The
dynamic effect with symbols is achieved through namespace tricks and yet
the compiler can always trust the symbols of the CL package.

I'm too much a beginner to tell if similar symbol concept is applicable
to Python.



More information about the Python-list mailing list