> If you don't follow this reasoning, please write a counter-proposal
> so that people have something to shoot down.
?
i just wanted to be sure it was done on purpose, and what were the
reasons for that.
-tomer
On 12/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> tomer filiba schrieb:
tomer filiba schrieb:
> my question is, how come classes don't create cell variables, like
> normal functions?
Not sure what you mean by "how come"? Why is the implementation
reacting as it is? Because the body of class is compiled as
a global code fragment, not as a nested one.
Or why is the imp
On 12/19/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> to my understanding of the object model, the code of snippet 1
> and snippet 2 should be equivalent. a class is just a "special function"
> that returns its locals automatically and passes them to the metaclass
> constructor:
>
> --- snippet 1
Raymond Hettinger schrieb:
> If you can find some other design that doesn't depend on the ordering of
> co_names, that would be nice; otherwise, we're adding a permanent
> complication to the compiler and establishing a new invariant that would
> have to be maintained by everyone hoping to generate
[Andrea Griffini]
> I'm experimenting with a patch for dictionary lookup caching, the
> main idea being avoiding the lookup of a constant (co_names) in
> a dictionary if the dictionary didn't change since last lookup.
. . .
> My opinion is that it would be by far better to do this ordering
> of co_
to my understanding of the object model, the code of snippet 1
and snippet 2 should be equivalent. a class is just a "special function"
that returns its locals automatically and passes them to the metaclass
constructor:
--- snippet 1 ---
class foo(object):
x = 5
def f(self):
print
Andrea Griffini schrieb:
> My opinion is that it would be by far better to do this ordering
> of co_names at compile time but I've no idea where to look
> for trying to make such a change.
>
> Can someone please point me in the right direction ?
It's all in Python/compiler.c. The names list is cr
On 12/19/06, Andrea Griffini <[EMAIL PROTECTED]> wrote:
I'm experimenting with a patch for dictionary lookup caching, the
main idea being avoiding the lookup of a constant (co_names) in
a dictionary if the dictionary didn't change since last lookup.
Currently the cache is held in a structure th
I'm experimenting with a patch for dictionary lookup caching, the
main idea being avoiding the lookup of a constant (co_names) in
a dictionary if the dictionary didn't change since last lookup.
Currently the cache is held in a structure that is parallel to
co_names (the LOAD_GLOBAL opcode uses opa