On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > You later stated that decorators were the wrong way of handling it. I > believe that the... > static <name> = <expression> > ...would require too many changes to what some regular python users have > come to expect from at least module namespaces. I have nothing > constructive to say about the function local case.
It looks like "static NAME = EXPR" is still pretty controversial. "NAME = static EXPR" seems to be getting universal +1s OTOH. > Allowing things like 'value < static (math.pi / 2)' brings up the > question of where the calculated value of (math.pi / 2) will be stored. > Presumably it would be stored in a function or module const table, and > that is fine. A new category of data stored on the function object, computed at function def time. It would be an array and there would be a new opcode to load values in this array in O(1) time. > But what does the operation: > <name> = static <expression> > ...do? In a function namespace, do we calculate expression, assign it > to the <name> local on function definition and call it good? That would be impossible; the local namespace doesn't exist when the function object is created (except for the cells used to reference variables in outer function scopes). > Or do we > load the stored evaluated <expression> each pass through during runtime, > making it effectively equivalent to: > <name> = <literal> > I hope it's the latter (assign it to the local from a const table at the > point of the '<name> = static ...' line). Yes, the latter should be good enough. [On Raymond's optimizing decorator] > You make a good point. It really is only usable in particular CPython > versions at any one time, though I am generally of a different opinion: > if for some desired operation X you can get identical functionality > and/or speed improvements during runtime without additional syntax, and > it is easy to use, then there is no reason to change syntax. There problem with hacks like that decorator is that if it misbehaves (e.g. you have a global that sometimes is reassigned) you end up debugging really hairy code. The semantics aren't 100% clear. I'm all for telling people "you can do that yourself" or even "here is a standard library module that solves your problem". But the solution needs to satisfy a certain cleanliness standard. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
