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

Groups > comp.lang.python > #10763 > 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 Terry Reedy <tjreedy@udel.edu> - 2011-08-02 16:23 -0400

#10763 — Re: Early binding as an option

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

[toc] | [standalone]

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

csiph-web