> If you really want locals that don't contribute to arguments, I'd be > much happier with something like a decorator, e.g.[1]: > > @with_consts(i=1, deftime=time.ctime()) > def foo(x, y=123, *args, **kw): > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime > > Then you don't have to mix parameter declarations with locals > definitions. > > Steve > > [1] I have no idea how implementable such a decorator would be. I'd > just like to see function constants declared separate from arguments > since they mean such different things.
I played around with this, and I think it's basically implementable:
I just update the function globals with the keywords passed to the decorator. The only problem is that updates to globals() aren't reflected in the function's globals:
Steven Bethard wrote: > I wrote: > > If you really want locals that don't contribute to arguments, I'd be > > much happier with something like a decorator, e.g.[1]:
> > @with_consts(i=1, deftime=time.ctime()) > > def foo(x, y=123, *args, **kw): > > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime
> > Then you don't have to mix parameter declarations with locals > > definitions.
> > Steve
> > [1] I have no idea how implementable such a decorator would be. I'd > > just like to see function constants declared separate from arguments > > since they mean such different things.
> I played around with this, and I think it's basically implementable:
On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan <ncogh...@iinet.net.au> wrote: >Steven Bethard wrote: >> I wrote: >> > If you really want locals that don't contribute to arguments, I'd be >> > much happier with something like a decorator, e.g.[1]:
>> > @with_consts(i=1, deftime=time.ctime()) >> > def foo(x, y=123, *args, **kw): >> > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime
>> > Then you don't have to mix parameter declarations with locals >> > definitions.
>> > Steve
>> > [1] I have no idea how implementable such a decorator would be. I'd >> > just like to see function constants declared separate from arguments >> > since they mean such different things.
>> I played around with this, and I think it's basically implementable:
I thought so too. I modified it to accept **presets as a keyword argument and generate constants and assignments from its values matching assignment names when the rhs was __frompresets__, e.g.,
>>> from makeconstpre import make_constants as pre >>> import time >>> @pre(verbose=True, deftime=time.ctime(), a=1, b=2, c=3, pi=__import__('math').pi) ... def foo(): ... deftime = __frompresets__ ... b, a = __frompresets__ ... c = __frompresets__ ... pi = __frompresets__ ... return locals() ... __frompresets__ : deftime --> Sat Jan 22 20:18:09 2005 __frompresets__ : ('b', 'a') --> (2, 1) __frompresets__ : c --> 3 __frompresets__ : pi --> 3.14159265359 locals --> <built-in function locals> >>> import dis >>> dis.dis(foo) 3 0 LOAD_CONST 1 ('Sat Jan 22 20:18:09 2005') 3 STORE_FAST 3 (deftime)
Not vary tested as yet, but seems to work. I want to eliminate redundant constants if the same name is assigned = __frompresets__ more than once. Right now I brute force generate another constant.
>> I wrote: >> > If you really want locals that don't contribute to arguments, I'd be >> > much happier with something like a decorator, e.g.[1]:
>> > @with_consts(i=1, deftime=time.ctime()) >> > def foo(x, y=123, *args, **kw): >> > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime
>> > Then you don't have to mix parameter declarations with locals >> > definitions.
>> > Steve
>> > [1] I have no idea how implementable such a decorator would be. I'd >> > just like to see function constants declared separate from arguments >> > since they mean such different things.
>> I played around with this, and I think it's basically implementable:
Bengt Richter wrote: > On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan <ncogh...@iinet.net.au> wrote:
>>Steven Bethard wrote:
>>>I wrote: >>> > If you really want locals that don't contribute to arguments, I'd be >>> > much happier with something like a decorator, e.g.[1]:
>>> > @with_consts(i=1, deftime=time.ctime()) >>> > def foo(x, y=123, *args, **kw): >>> > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime
>>> > Then you don't have to mix parameter declarations with locals >>> > definitions.
>>> > Steve
>>> > [1] I have no idea how implementable such a decorator would be. I'd >>> > just like to see function constants declared separate from arguments >>> > since they mean such different things.
>>>I played around with this, and I think it's basically implementable:
> I thought so too. I modified it to accept **presets as a keyword argument > and generate constants and assignments from its values matching assignment names > when the rhs was __frompresets__, e.g.,
> >>> from makeconstpre import make_constants as pre > >>> import time > >>> @pre(verbose=True, deftime=time.ctime(), a=1, b=2, c=3, pi=__import__('math').pi) > ... def foo(): > ... deftime = __frompresets__ > ... b, a = __frompresets__ > ... c = __frompresets__ > ... pi = __frompresets__ > ... return locals() > ... > __frompresets__ : deftime --> Sat Jan 22 20:18:09 2005 > __frompresets__ : ('b', 'a') --> (2, 1) > __frompresets__ : c --> 3 > __frompresets__ : pi --> 3.14159265359 > locals --> <built-in function locals>
Hmm... Having to state deftime = __frompresets__ when you've already stated deftime=time.ctime() seems a little redundant to me...
On Sun, 23 Jan 2005 13:14:10 -0700, Steven Bethard <steven.beth...@gmail.com> wrote: >Bengt Richter wrote: >> On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan <ncogh...@iinet.net.au> wrote:
[Steven Bethard] >>>> > If you really want locals that don't contribute to arguments, I'd be >>>> > much happier with something like a decorator, e.g.[1]:
>>>> > @with_consts(i=1, deftime=time.ctime()) >>>> > def foo(x, y=123, *args, **kw): >>>> > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime
>>>> > Then you don't have to mix parameter declarations with locals >>>> > definitions.
[Bengt Richter] >> I thought so too. I modified it to accept **presets as a keyword argument >> and generate constants and assignments from its values matching assignment names >> when the rhs was __frompresets__, e.g.,
>> >>> from makeconstpre import make_constants as pre >> >>> import time >> >>> @pre(verbose=True, deftime=time.ctime(), a=1, b=2, c=3, pi=__import__('math').pi) >> ... def foo(): >> ... deftime = __frompresets__ >> ... b, a = __frompresets__ >> ... c = __frompresets__ >> ... pi = __frompresets__ >> ... return locals() >> ... >> __frompresets__ : deftime --> Sat Jan 22 20:18:09 2005 >> __frompresets__ : ('b', 'a') --> (2, 1) >> __frompresets__ : c --> 3 >> __frompresets__ : pi --> 3.14159265359 >> locals --> <built-in function locals>
[Steven Bethard] >Hmm... Having to state > deftime = __frompresets__ >when you've already stated > deftime=time.ctime() >seems a little redundant to me...
Yeah, but as a quick hack, it made the byte code twiddling all changing byte codes in-place. I didn't want to verify that byte code wouldn't need relocation fixups if I inserted something, (unless of course within a suite with branches or loops) but hopefully it's easily so at the beginning.
BTW, unlike default arguments, varname = __frompresets__ will work anywhere in the code, (for the current decorator version) and the generated byte code will have a load of an appropriate constant (the same one if the same name is being assigned). This would be tricky to get right if done in a hidden just-in-time manner only in branches that used the values, but hidden initialization of the whole presets set at the beginning should be relatively easy if there are no relocation problems. So, e.g., for
>> for the current version, except that it will be hidden.
>Cool! Keep us posted. I assume you'll put this into the Cookbook?
Not ready for prime time, I guess, but I made a module that does presets and also adjusts parameters and count to do currying without nested function calling in the curried function.
Now I have to see whether I can optimize the result with Raymond's make_constants as two decorators in a row... (pre without keyword args is an alias for Raymond's make_constants, just handy for the moment)
>>> from pre import pre >>> @pre(verbose=True) ... @presets(verbose=True, a=1, b=2, deftime=__import__('time').ctime()) ... def foo(): ... print (a, b) ... print deftime ... print __name__ ...
presets: -- "name(?)" means name may be unused a = 1 b = 2 deftime = 'Mon Jan 24 12:29:21 2005'
>>> for the current version, except that it will be hidden.
>>Cool! Keep us posted. I assume you'll put this into the Cookbook?
>Not ready for prime time, I guess, but I made a module that does presets >and also adjusts parameters and count to do currying without nested function >calling in the curried function.
> presets: -- "name(?)" means name may be unused > y = 444
> >>> bar(2) > 888 > >>> bar(2, 3) > Traceback (most recent call last): > File "<stdin>", line 1, in ? > TypeError: bar() takes at most 1 argument (2 given) > >>> bar() > 1332
Not much reaction, so I guess I won't see it if any, since I am going off line for a while. BTW, this exercise makes me realize that you could do some other interesting things too, if you put your mind to it. E.g., it might be interesting to inject properties into the local namespace of a function, so that e.g., x=1 would would trigger an effect like someobj.x = 1, where type(someobj).x was a property. It wouldn't be too hard to make
@addprop(verbose=True, x=property(getx, setx, delx)) def foo(): x = 123 return x
etc. Maybe could be used to monitor access to specific locals for debug, or other uses. Haven't even begun to think about that.
Another thing is to turn selected local defs into constants, since executing the aggregation-of-parts code that accomplished the def may well be unchanging. This would reduce the execution cost of nested functions. I guess that is a specific case of a more general sticky-evaluate-rhs-once kind of directive for locals that are only assigned in one place. special sentinels could be used in the decorator keyword values to indicate this treatment of the associated name, e.g. from presets import presets @presets(x=presets.STICKY, y=123) def foo(y): x = initx() # done once on the first call, making x references constant after that return x*y
Another thing that could be done is to inject pre and post things like atexit stuff. Also maybe some adaptation things that is just a buzzword so far that I haven't explored.
BTW, is there another op that needs relocation besides JUMP_ABSOLUTE?
I was wondering about doing code mods by messing with an ast, but a decorator would have to chase down the source and reparse I guess, in order to do that. It would be interesting to be able to hook into ast stuff with some kind of metacompile hook (hand waving ;-)