Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10754 > unrolled thread

Re: Early binding as an option

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Early binding as an option Chris Rebert <clp2@rebertia.com> - 2011-08-02 11:03 -0700
    Re: Early binding as an option Teemu Likonen <tlikonen@iki.fi> - 2011-08-02 22:12 +0300

#10754 — Re: Early binding as an option

On Tue, Aug 2, 2011 at 9:55 AM, Chris Angelico <rosuav@gmail.com> wrote:
> 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.
>
> First off: Is there any way to request/cause some names to be bound
> early?

Nope. Even if you "freeze" a variable's value via a closure, I don't
believe it gets particularly optimized.

<snip>
> As an example of this difference, Pike uses early binding for some
> things; when I did the perfect numbers testing in the other thread
> (discussion thread, not thread of execution!), Pike performed
> significantly better; I believe this is in part due to the formal
> declarations of variables, and the consequential simplification of
> local code, although since there are no globals being looked up here,
> there's little to be gained from those.

"in part". There are very likely additional factors at work here.
Also, have you looked at Cython? I would guess that it can bypass a
lot of the late binding.

> Is this the realm of JIT compilation, or can it be done in regular CPython?

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.

The CPython devs are reluctant to accept the increased complexity and
size of a JIT engine (see Unladen Swallow).
Anything else would probably involve a similarly unpalatable level of
complexity or require changing Python-the-language.

I'm pretty sure optional early binding has been proposed in the past;
try trawling the list archives.

Cheers,
Chris

[toc] | [next] | [standalone]

#10760

* 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web