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

Groups > comp.lang.python > #10769 > 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 Gelonida N <gelonida@gmail.com> - 2011-08-03 00:21 +0200

#10769 — Re: Early binding as an option

On 08/03/2011 12:08 AM, Chris Angelico wrote:
> With the local-variable-snapshot technique ("len = len"), can anything
> be optimized, since the parser can guarantee that nothing ever
> reassigns to it? If not, perhaps this would be a place where something
> might be implemented:
> 
> @const(len,max) # maybe this
> def maxline(f):
>    @const len,max # or this
>    n = 0
>    for line in somefile:
>        n = max(n,len(line))
>    return n
> 
> Some notation like this could tell the interpreter, "I don't expect
> 'len' or 'max' to be rebound during the execution of this function.
> You're free to produce wrong results if either is."
> 
> So... Would this potentially produce wrong results? Would it be of any
> use, or would its benefit be only valued in times when the whole
> function needs to be redone in C?
> 
> Chris Angelico

I think the idea of having pragmas / directives to tell the interpreter
that certain symbols could be bound early is intersting and might help
optimizing some inner loops without having to explicitely assign to
local vars.

On the other hand: It might be interesting, that the early binding would
just take place when python is invoked with -O

Thus you could still do a lot of debug / tracing magic during
development and only production code would do the late binding.

[toc] | [standalone]

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

csiph-web