Grokbase › Groups › Python › python-list › January 2005
FAQ

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, y3, *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:

py> import new
py> class with_consts(object):
... def __init__(self, **consts):
... self.consts = consts
... def __call__(self, func):
... return new.function(func.func_code,
... dict(globals(), **self.consts))
...
py> @with_consts(y3)
... def f(x):
... return x*y, str
...
py> f(2)
(246, <type 'str'>)

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:

py> str = 5
py> f(2)
(246, <type 'str'>)

Steve

Search Discussions

  • Nick Coghlan at Jan 22, 2005 at 6:22 am ⇧

    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, y3, *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:
    Raymond's constant binding decorator is probably a good model for how to do it:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940

    Cheers,
    Nick.

    --
    Nick Coghlan | ncoghlan at email.com | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
  • Bengt Richter at Jan 23, 2005 at 4:28 am ⇧

    On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan 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, y3, *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:
    Raymond's constant binding decorator is probably a good model for how to do it:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940
    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)

    4 6 LOAD_CONST 2 ((2, 1))
    9 UNPACK_SEQUENCE 2
    12 STORE_FAST 2 (b)
    15 STORE_FAST 0 (a)

    5 18 LOAD_CONST 3 (3)
    21 STORE_FAST 1 (c)

    6 24 LOAD_CONST 4 (3.1415926535897931)
    27 STORE_FAST 4 (pi)

    7 30 LOAD_CONST 5 (<built-in function locals>)
    33 CALL_FUNCTION 0
    36 RETURN_VALUE
    foo()
    {'a': 1, 'c': 3, 'pi': 3.1415926535897931, 'b': 2, 'deftime': 'Sat Jan 22 20:18:09 2005'}

    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.

    Regards,
    Bengt Richter
  • Steven Bethard at Jan 23, 2005 at 8:14 pm ⇧

    Bengt Richter wrote:
    On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan 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, y3, *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:
    Raymond's constant binding decorator is probably a good model for how to do it:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940

    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...

    Steve
  • Bengt Richter at Jan 24, 2005 at 7:30 am ⇧

    On Sun, 23 Jan 2005 13:14:10 -0700, Steven Bethard wrote:
    Bengt Richter wrote:
    On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan 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, y3, *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.
    [...]

    [Nick Coghlan]
    Raymond's constant binding decorator is probably a good model for how to do it:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940
    [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
    presets = dict(a=1, b=2, deftime=__import__('time').ctime())
    in the decorator args, the next version will act as if the decorated
    function had the source code
    print '%s = __frompresets__' % ', '.join(sorted(presets))
    a, b, deftime = __frompresets__

    for the current version, except that it will be hidden.

    Regards,
    Bengt Richter
  • Steven Bethard at Jan 24, 2005 at 7:31 am ⇧

    Bengt Richter wrote:
    So, e.g., for
    presets = dict(a=1, b=2, deftime=__import__('time').ctime())
    in the decorator args, the next version will act as if the decorated
    function had the source code
    print '%s = __frompresets__' % ', '.join(sorted(presets))
    a, b, deftime = __frompresets__

    for the current version, except that it will be hidden.
    Cool! Keep us posted. I assume you'll put this into the Cookbook?

    Steve
  • Bengt Richter at Jan 24, 2005 at 8:35 pm ⇧

    On Mon, 24 Jan 2005 00:31:17 -0700, Steven Bethard wrote:
    Bengt Richter wrote:
    So, e.g., for
    presets = dict(a=1, b=2, deftime=__import__('time').ctime())
    in the decorator args, the next version will act as if the decorated
    function had the source code
    print '%s = __frompresets__' % ', '.join(sorted(presets))
    a, b, deftime = __frompresets__

    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.
    from presets import presets, curry
    @presets(verbose=True, a=1, b=2, deftime=__import__('time').ctime())
    ... def foo():
    ... print (a, b)
    ... print deftime
    ...

    presets: -- "name(?)" means name may be unused
    a = 1
    b = 2
    deftime = 'Mon Jan 24 12:16:07 2005'
    foo()
    (1, 2)
    Mon Jan 24 12:16:07 2005
    @curry(verbose=True, yD4)
    ... def bar(x=3, y=4):
    ... return x*y
    ...

    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
    import dis
    dis.dis(bar)
    1 0 LOAD_CONST 1 (444)
    3 STORE_FAST 1 (y)

    3 6 LOAD_FAST 0 (x)
    9 LOAD_FAST 1 (y)
    12 BINARY_MULTIPLY
    13 RETURN_VALUE
    dis.dis(foo)
    1 0 LOAD_CONST 1 ((1, 2, 'Mon Jan 24 12:16:07 2005'))
    3 UNPACK_SEQUENCE 3
    6 STORE_FAST 0 (a)
    9 STORE_FAST 1 (b)
    12 STORE_FAST 2 (deftime)

    3 15 LOAD_FAST 0 (a)
    18 LOAD_FAST 1 (b)
    21 BUILD_TUPLE 2
    24 PRINT_ITEM
    25 PRINT_NEWLINE

    4 26 LOAD_FAST 2 (deftime)
    29 PRINT_ITEM
    30 PRINT_NEWLINE
    31 LOAD_CONST 0 (None)
    34 RETURN_VALUE

    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'

    __name__ --> __main__
    foo()
    (1, 2)
    Mon Jan 24 12:29:21 2005
    __main__
    dis.dis(foo)
    1 0 LOAD_CONST 1 ((1, 2, 'Mon Jan 24 12:29:21 2005'))
    3 UNPACK_SEQUENCE 3
    6 STORE_FAST 0 (a)
    9 STORE_FAST 1 (b)
    12 STORE_FAST 2 (deftime)

    3 15 LOAD_FAST 0 (a)
    18 LOAD_FAST 1 (b)
    21 BUILD_TUPLE 2
    24 PRINT_ITEM
    25 PRINT_NEWLINE

    4 26 LOAD_FAST 2 (deftime)
    29 PRINT_ITEM
    30 PRINT_NEWLINE

    5 31 LOAD_CONST 2 ('__main__')
    34 PRINT_ITEM
    35 PRINT_NEWLINE
    36 LOAD_CONST 0 (None)
    39 RETURN_VALUE

    Regards,
    Bengt Richter
  • Bengt Richter at Jan 25, 2005 at 9:18 am ⇧

    On Mon, 24 Jan 2005 20:35:09 GMT, bokr at oz.net (Bengt Richter) wrote:
    On Mon, 24 Jan 2005 00:31:17 -0700, Steven Bethard wrote:

    Bengt Richter wrote:
    So, e.g., for
    presets = dict(a=1, b=2, deftime=__import__('time').ctime())
    in the decorator args, the next version will act as if the decorated
    function had the source code
    print '%s = __frompresets__' % ', '.join(sorted(presets))
    a, b, deftime = __frompresets__

    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.
    from presets import presets, curry
    @presets(verbose=True, a=1, b=2, deftime=__import__('time').ctime())
    ... def foo():
    ... print (a, b)
    ... print deftime
    ...

    presets: -- "name(?)" means name may be unused
    a = 1
    b = 2
    deftime = 'Mon Jan 24 12:16:07 2005'
    foo()
    (1, 2)
    Mon Jan 24 12:16:07 2005
    @curry(verbose=True, yD4)
    ... def bar(x=3, y=4):
    ... return x*y
    ...

    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, y3)
    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 ;-)

    Bye for a while.

    Regards,
    Bengt Richter
  • Steven Bethard at Jan 25, 2005 at 6:58 pm ⇧

    Bengt Richter wrote:
    On Mon, 24 Jan 2005 20:35:09 GMT, bokr at oz.net (Bengt Richter) wrote:

    from presets import presets, curry
    @presets(verbose=True, a=1, b=2, deftime=__import__('time').ctime())
    ... def foo():
    ... print (a, b)
    ... print deftime
    ...

    presets: -- "name(?)" means name may be unused
    a = 1
    b = 2
    deftime = 'Mon Jan 24 12:16:07 2005'

    foo()
    (1, 2)
    Mon Jan 24 12:16:07 2005
    Not much reaction
    Sorry, it's definitely cool -- I was just waiting for you to post the
    Cookbook link so I could see how you did it. ;)

    Steve
  • Steven Bethard at Jan 23, 2005 at 8:08 pm ⇧

    Nick Coghlan 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, y3, *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:

    Raymond's constant binding decorator is probably a good model for how to
    do it:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940
    Yeah, I thought about this recipe, but opcodes always scare me too much. ;)

    Steve

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJan 22, '05 at 1:57a
activeJan 25, '05 at 6:58p
posts10
users3
websitepython.org

3 users in discussion

Steven Bethard: 5 posts Bengt Richter: 4 posts Nick Coghlan: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase