Radical: listing decorators compared to atexit function registration

Discussion in 'Python' started by Bengt Richter, Aug 25, 2004.

  1. Still looking for a unifying concept ;-)

    It struck me that

    @deco1
    @deco2
    def foo():pass

    uses '@' to register at-next-name-binding processing in a way similar to atexit's
    registering of processing to happen at ('@' ;-) exit.

    IOW, it is setting up processing for an event (synchronous in this case)
    that is expected to happen in the future.

    I like that meaning of '@' -- i.e., @event_handler_defining_expression seems like
    a nice general reading of an 'at'-symbol.

    In the case of function decoration, the event is implicitly the completion of the
    execution of next-in-code-sequence function definition, intercepting
    just before name-binding. And a chain of interceptions works in order.

    In the case of current decorators, deco1 etc must be expressions resulting in
    functions. By default, the functions are hooked into a chain of at-next-name-binding
    processing that gets triggered by the def name binding. This is the current use case.

    However, the broader concept is for @expression to cause registration of a generalized
    event handler into an event recognition/handling mechanism. The concept can be embellished
    with one-shot vs repeated and with or without timeout, multiple events, etc., but leave
    that for later, so long as the door is not closed to it.

    If @expression evaluating to a function defaults to a certain meaning, it should be
    possible to spell it out using a compatible general and full spelling. OTTOMH ISTM
    that the natural alternative to returning a function or ordinary callable would be
    to return an object that the infrastructure would recognize and register into the
    appropriate alternative event-handling place.

    One way would be if the object were marked in a similar way that an object gets
    marked as a descriptor (which happens with a __get__ method etc). Perhaps __handler__ ?
    Thus you could write a class with a __handler__ method and instantiate it with info
    re what event to recognize and other particulars. Then decorator syntax spelled out
    might look (in concept, this is not a design spec ;-) like:

    @my_next_binding_handler(func=deco1, event='before_next_local_binding')
    @my_next_binding_handler(func=deco2, event='before_next_local_binding')
    def foo():pass

    Note that you could potentially define object attribute access events and have another way
    to define properties, if you passed info to your handler constructor specifying name and
    namespace. Obviously the infrastructure would have to grow some event-handling and
    relevant registration etc magic.

    This is essentially a push to start thinking about bringing generalized event-driven
    programming nicely into python. I'm suggesting that decorators can be seen as special
    one-shot event handlers for a local binding event. A GUI is obviously a source of many
    user action events, and a way to say @mouseover('this','that') to instantiate and
    register some code might be neat. Ditto for i/o related events. This brings in thread
    issues though, and event queuing etc. But that can be deferred. We can just deal with
    synchronous events for the time being. Hm... recoverable exceptions anyone ;-)

    OTOH, this may all just be a symptom of attempted personal stress escape ;-)

    Regards,
    Bengt Richter
    Bengt Richter, Aug 25, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JoanneC
    Replies:
    0
    Views:
    334
    JoanneC
    Aug 26, 2003
  2. John
    Replies:
    3
    Views:
    344
    Lucas Tam
    Apr 17, 2005
  3. Arien Malec

    PEP 318 decorators are not Decorators

    Arien Malec, Aug 13, 2004, in forum: Python
    Replies:
    11
    Views:
    567
    Arien Malec
    Aug 16, 2004
  4. Arien Malec

    PEP318: radical notion

    Arien Malec, Aug 23, 2004, in forum: Python
    Replies:
    14
    Views:
    517
    Arien Malec
    Aug 27, 2004
  5. Idan Sofer

    [ANN] Radical 0.7

    Idan Sofer, Sep 12, 2003, in forum: Ruby
    Replies:
    0
    Views:
    111
    Idan Sofer
    Sep 12, 2003
Loading...

Share This Page