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

Groups > comp.lang.python > #10763

Re: Early binding as an option

Show key headers only | View raw

On 8/2/2011 12:55 PM, Chris Angelico wrote:
> As I understand it, Python exclusively late-binds names; when you
> define a function, nothing is ever pre-bound.

By 'pre-bound' you presumably mean bound at definition time rather than 
call time. Default arg objects *are* pre-computed and pre-bound to 
internal slots at definition time.

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

Three approaches to machine efficiency.

1. Better algorithm: Python's people efficiency makes this easier than 
in most other languages.

2. Hand-optimize the code that actually chew up time (as revealed by 
profiler). This often means removing repeated expressions *and* global 
names from inner loops.

     _len = len
     for line in somefile:
         n = _len(line)

*might* give a worthwhile speedup in a function if not too much else 
happends in the loop. But the CPython global name lookup code (in C) has 
been thoroughly examined and optimized as best as several developers 
could think of.

3. Convert critical code to native language (or C).

The idea of 'early binding' comes up periodically but I do not remember 
many concrete proposals.

-- 
Terry Jan Reedy

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Early binding as an option Terry Reedy <tjreedy@udel.edu> - 2011-08-02 16:23 -0400

csiph-web