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

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

Early binding as an option

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

Contents

  Early binding as an option Chris Angelico <rosuav@gmail.com> - 2011-08-02 17:55 +0100
    Re: Early binding as an option Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-02 21:02 +0200

#10747 — Early binding as an option

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? and secondly, should there be?

Argument against: Late binding is a Good Thing, and having some things
bound early would be confusing.

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.

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.

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.

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

Chris Angelico

[toc] | [next] | [standalone]

#10758

Chris Angelico <rosuav@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
> CPython?

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.

-- Alain.

[toc] | [prev] | [standalone]

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

csiph-web