Decorator Base Class: Needs improvement.

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Ron_Adam

    #1

    Decorator Base Class: Needs improvement.


    Hi, Thanks again for all the helping me understand the details of
    decorators.

    I put together a class to create decorators that could make them a lot
    easier to use.

    It still has a few glitches in it that needs to be addressed.

    (1) The test for the 'function' object needs to not test for a string
    but an object type instead.

    (2) If the same decorator instance is stacked, it will get locked in a
    loop. But stacking different instances created from the same
    decorator object works fine.

    (3) It has trouble if a decorator has more than one argument.


    But I think all of these things can be fixed. Would this be something
    that could go in the builtins library? (After any issues are fixed
    first of course.)

    When these are stacked, they process all the prepossess's first, call
    the decorator, then process all the postprocess's. It just worked out
    that way, which was a nice surprise and makes this work a bit
    different than the standard decorators.

    Cheers,
    Ron

    #---start---

    class Decorator(objec t):
    """
    Decorator - A class to make decorators with.

    self.function - name of function decorated.
    self.arglist - arguments of decorator
    self.preprocess - over ride to preprocess function arguments.
    self.postproces s - over ride to postprocess function
    return value.

    Example use:
    class mydecorator(Dec orate):
    def self.preprocess (self, args):
    # process args
    return args
    def self.postproces s(self, results):
    # process results
    return results

    deco = mydecorator()

    @deco
    def function(args):
    # function body
    return args
    """
    function = None
    arglist = []
    def __call__(self, arg):
    self.arglist.ap pend(arg)
    def _wrapper( args):
    pre_args = self.preprocess (args)
    result = self.function(p re_args)
    return self.postproces s(result)
    if 'function' in str(arg):
    self.arglist = self.arglist[:-1]
    self.function = arg
    return _wrapper
    return self
    def preprocess(self , args):
    return args
    def postprocess(sel f, result):
    return result

    class mydecorator(Dec orater):
    def preprocess(self , args):
    args = 2*args
    return args
    def postprocess(sel f, args):
    args = args.upper()
    args = args + str(self.arglis t[0])
    return args
    deco = mydecorator()

    @deco('xyz')
    def foo(text):
    return text

    print foo('abc')


    #---end---


  • Ron_Adam

    #2
    Re: Decorator Base Class: Needs improvement.


    Ok, that post may have a few(dozen?) problems in it. I got glitched
    by idles not clearing variables between runs, so it worked for me
    because it was getting values from a previous run.

    This should work better, fixed a few things, too.

    The decorators can now take more than one argument.
    The function and arguments lists initialize correctly now.

    It doesn't work with functions with more than one variable. It seems
    tuples don't unpack when given to a function as an argument. Any way
    to force it?


    class Decorator(objec t):
    """
    Decorator - A base class to make decorators with.

    self.function - name of function decorated.
    self.arglist - arguments of decorator
    self.preprocess - over ride to preprocess function arguments.
    self.postproces s - over ride to postprocess function
    return value.

    Example use:
    class mydecorator(Dec orate):
    def self.preprocess (self, args):
    # process args
    return args
    def self.postproces s(self, results):
    # process results
    return results

    deco = mydecorator()

    @deco
    def function(args):
    # function body
    return args
    """
    def __init__(self):
    self.function = None
    self.arglist = []
    def __call__(self, *arg):
    if len(arg) == 1:
    arg = arg[0]
    self.arglist.ap pend(arg)
    def _wrapper( *args):
    if len(args) == 1:
    args = args[0]
    pre_args = self.preprocess (args)
    result = self.function(p re_args)
    return self.postproces s(result)
    if 'function' in str(arg):
    self.arglist = self.arglist[:-1]
    self.function = arg
    return _wrapper
    return self
    def preprocess(self , args):
    return args
    def postprocess(sel f, result):
    return result


    #---3---
    class mydecorator(Dec orator):
    def preprocess(self , args):
    args = 2*args
    return args
    def postprocess(sel f, args):
    args = args.upper()
    args = args + str(self.arglis t[0])
    return args
    deco = mydecorator()

    @deco('xyz')
    def foo(text):
    return text
    print foo('abc')


    #---2---
    class decorator2(Deco rator):
    def preprocess(self , args):
    return args+sum(self.a rglist[0])
    def postprocess(sel f, args):
    return args
    deco2 = decorator2()

    @deco2(1,2)
    def foo(a):
    return a
    print foo(1)

    # This one doesn't work yet.
    #---3---
    class decorator3(Deco rator):
    pass
    deco3 = decorator3()

    @deco3
    def foo(a,b):
    return a,b
    print foo(1,3)


    Comment

    • Steve Holden

      #3
      Re: Decorator Base Class: Needs improvement.

      Ron_Adam wrote:[color=blue]
      > Ok, that post may have a few(dozen?) problems in it. I got glitched
      > by idles not clearing variables between runs, so it worked for me
      > because it was getting values from a previous run.
      >
      > This should work better, fixed a few things, too.
      >
      > The decorators can now take more than one argument.
      > The function and arguments lists initialize correctly now.
      >[/color]
      Ron:

      I've followed your attempts to understand decorators with interest, and
      have seen you engage in conversation with many luminaries of the Python
      community, so I hesitate at this point to interject my own remarks.

      In a spirit of helpfulness, however, I have to ask whether your
      understanding of decorators is different from mine because you don't
      understand them or because I don't.

      You have several times mentioned the possibility of a decorator taking
      more than one argument, but in my understanding of decorators this just
      wouldn't make sense. A decorator should (shouldn't it) take precisely
      one argument (a function or a method) and return precisely one value (a
      decorated function or method).
      [color=blue]
      > It doesn't work with functions with more than one variable. It seems
      > tuples don't unpack when given to a function as an argument. Any way
      > to force it?
      >
      >
      > class Decorator(objec t):[/color]
      [...]

      Perhaps we need to get back to basics?

      Do you understand what I mean when I say a decorator should take one
      function as its argument and it should return a function?

      regards
      Steve
      --
      Steve Holden +1 703 861 4237 +1 800 494 3119
      Holden Web LLC http://www.holdenweb.com/
      Python Web Programming http://pydish.holdenweb.com/

      Comment

      • Kay Schluehr

        #4
        Re: Decorator Base Class: Needs improvement.

        Steve Holden wrote:
        [color=blue]
        > You have several times mentioned the possibility of a decorator[/color]
        taking[color=blue]
        > more than one argument, but in my understanding of decorators this[/color]
        just[color=blue]
        > wouldn't make sense. A decorator should (shouldn't it) take precisely[/color]
        [color=blue]
        > one argument (a function or a method) and return precisely one value[/color]
        (a[color=blue]
        > decorated function or method).[/color]

        Yes. I think this sould be fixed into the minds of the people exacly
        this way You state it:

        When writing

        @decorator(x,y)
        def f():
        ....

        not the so called "decorator" function but decorator(x,y) is the
        decorating function and decorator(x,y) is nothing but a callable object
        that takes f as parameter. A little correcture of Your statement: it is
        NOT nessacary that a function or method will be returned from a
        decorator.

        def decorator(x,y):
        def inner(func):
        return x+y
        return inner

        @decorator(1,2)
        def f():pass
        [color=blue][color=green][color=darkred]
        >>> f[/color][/color][/color]
        3

        This is perfectly valid allthough not very usefull ;)

        Regards,
        Kay

        Comment

        • Bengt Richter

          #5
          Re: Decorator Base Class: Needs improvement.

          On 5 Apr 2005 00:54:25 -0700, "Kay Schluehr" <kay.schluehr@g mx.net> wrote:
          [color=blue]
          >Steve Holden wrote:
          >[color=green]
          >> You have several times mentioned the possibility of a decorator[/color]
          >taking[color=green]
          >> more than one argument, but in my understanding of decorators this[/color]
          >just[color=green]
          >> wouldn't make sense. A decorator should (shouldn't it) take precisely[/color]
          >[color=green]
          >> one argument (a function or a method) and return precisely one value[/color]
          >(a[color=green]
          >> decorated function or method).[/color]
          >[/color]
          I agree from an English language point of view. I.e., a verber is
          something that does the verbing, so a decorator ought to be the thing
          that does the decorating, which is the function/callable(s) resulting
          on stack from the evaluation of the @-line.

          In the case of a single @deco name, the evaluation is trivial, and
          the difference between the @-expression and the resulting callable
          might be overlooked. Full-fledged general expressions after the '@'
          are for some reason disallowed, but it is handy to allow attribute
          access and calling in the syntax, so the relevant Grammar rules are:

          From the 2.4 Grammar, the key part seems to be

          decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
          decorators: decorator+
          funcdef: [decorators] 'def' NAME parameters ':' suite

          and further on

          dotted_name: NAME ('.' NAME)*

          So the Python Grammar's name for the @-expression is just plain "decorator"
          which conflicts with my English-based reading of the word ;-/

          So it appears the intent is to call the entire @-line the "decorator"
          and I guess to have a name for what evaluating the @-line returns on the
          stack, we could call it the "decorating callable" since it is what takes
          the function parameter as its first parameter and decorates the function
          and returns the decorated function.

          But I don't like it, English-wise. I would rather call the @-line
          the "decorator expression" and what it evaluates to the "decorator. "

          Can we change the grammar with s/decorator/decorator_expr/ ?
          [color=blue]
          >Yes. I think this sould be fixed into the minds of the people exacly
          >this way You state it:[/color]
          I think we may be agreeing in principle but with different words ;-)[color=blue]
          >
          >When writing
          >
          >@decorator(x,y )
          >def f():
          > ....
          >
          >not the so called "decorator" function but decorator(x,y) is the[/color]
          ^--(the result of evaluating)[color=blue]
          >decorating function and decorator(x,y) is nothing but a callable object[/color]
          ^--(the result of evaluating)[color=blue]
          >that takes f as parameter. A little correcture of Your statement: it is
          >NOT nessacary that a function or method will be returned from a
          >decorator.[/color]

          Yes, in fact it could even perversely be colluding with a known succeeding
          decorator callable to pass info strangely, doing strange things, e.g.,
          [color=blue][color=green][color=darkred]
          >>> trick = ['spam', 'eggs']
          >>> def choose_name(tup ):[/color][/color][/color]
          ... nx, f = tup
          ... f.func_name = trick[nx]
          ... return f
          ...[color=blue][color=green][color=darkred]
          >>> def namedeco(nx=1):[/color][/color][/color]
          ... return lambda f, nx=nx:(nx, f)
          ...[color=blue][color=green][color=darkred]
          >>> @choose_name[/color][/color][/color]
          ... @namedeco()
          ... def foo(): pass
          ...[color=blue][color=green][color=darkred]
          >>> foo[/color][/color][/color]
          <function eggs at 0x02EE8E64>[color=blue][color=green][color=darkred]
          >>> @choose_name[/color][/color][/color]
          ... @namedeco(0)
          ... def foo(): pass
          ...[color=blue][color=green][color=darkred]
          >>> foo[/color][/color][/color]
          <function spam at 0x02EE8DF4>

          I.e., namedeco evaluates to the lambda as decorator function,
          and that passes a perverse (nx, f) tuple on to choose_name, instead
          of a normal f.
          [color=blue]
          >
          >def decorator(x,y):
          > def inner(func):
          > return x+y
          > return inner
          >
          >@decorator(1,2 )
          >def f():pass
          >[color=green][color=darkred]
          >>>> f[/color][/color]
          >3
          >
          >This is perfectly valid allthough not very usefull ;)
          >[/color]

          Perhaps even less useful, the final decorator can return something
          arbitrary, as only the name in the def matters at that point in
          the execution (as a binding target name), so:
          [color=blue][color=green][color=darkred]
          >>> def dumbdeco(f): return 'something dumb'[/color][/color][/color]
          ...[color=blue][color=green][color=darkred]
          >>> @dumbdeco[/color][/color][/color]
          ... def foo(): pass
          ...[color=blue][color=green][color=darkred]
          >>> foo[/color][/color][/color]
          'something dumb'

          Hm, maybe some use ...
          [color=blue][color=green][color=darkred]
          >>> def keydeco(name):[/color][/color][/color]
          ... return lambda f: (name, f)
          ...[color=blue][color=green][color=darkred]
          >>> @keydeco('pooh_ foo')[/color][/color][/color]
          ... def foo(): pass
          ...[color=blue][color=green][color=darkred]
          >>> @keydeco('tigge r_bar')[/color][/color][/color]
          ... def bar(): pass
          ...[color=blue][color=green][color=darkred]
          >>> dict([foo, bar])[/color][/color][/color]
          {'pooh_foo': <function foo at 0x02EE8DBC>, 'tigger_bar': <function bar at 0x02EE8DF4>}

          .... nah ;-)


          Anyway, I think a different name for what comes after the "@" and the
          callable that that (very limited) expression is supposed to return
          would clarify things. My conceptual model is

          @decorator_expr ession # => decorator
          def decorating_targ et(...):
          ...

          Regards,
          Bengt Richter

          Comment

          • Kay Schluehr

            #6
            Re: Decorator Base Class: Needs improvement.

            Bengt Richter wrote:
            [color=blue]
            > From the 2.4 Grammar, the key part seems to be
            >
            > decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
            > decorators: decorator+
            > funcdef: [decorators] 'def' NAME parameters ':' suite
            >
            > and further on
            >
            > dotted_name: NAME ('.' NAME)*
            >
            > So the Python Grammar's name for the @-expression is just plain[/color]
            "decorator"[color=blue]
            > which conflicts with my English-based reading of the word ;-/[/color]

            What about playing with the words decorator/decoration? The allegoric
            meaning of the decorator

            def deco(f):
            pass

            would be: f is "vanishing under decoration" - all is vanity.

            In the example deco would be both a decorator and a decoration. In
            other examples deco were a decorator and deco(x,y) the decoration.

            Regards,
            Kay

            Comment

            • Kay Schluehr

              #7
              Re: Decorator Base Class: Needs improvement.

              Bengt Richter wrote:
              [color=blue]
              > From the 2.4 Grammar, the key part seems to be
              >
              > decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
              > decorators: decorator+
              > funcdef: [decorators] 'def' NAME parameters ':' suite
              >
              > and further on
              >
              > dotted_name: NAME ('.' NAME)*
              >
              > So the Python Grammar's name for the @-expression is just plain[/color]
              "decorator"[color=blue]
              > which conflicts with my English-based reading of the word ;-/[/color]

              What about playing with the words decorator/decoration? The allegoric
              meaning of the decorator

              def deco(f):
              pass

              would be: f is "vanishing under decoration" - all is vanity.

              In the example deco would be both a decorator and a decoration. In
              other cases deco were a decorator and deco(x,y) the decoration.

              Regards,
              Kay

              Comment

              • Ron_Adam

                #8
                Re: Decorator Base Class: Needs improvement.

                On Tue, 05 Apr 2005 02:55:35 -0400, Steve Holden <steve@holdenwe b.com>
                wrote:
                [color=blue]
                >Ron_Adam wrote:[color=green]
                >> Ok, that post may have a few(dozen?) problems in it. I got glitched
                >> by idles not clearing variables between runs, so it worked for me
                >> because it was getting values from a previous run.
                >>
                >> This should work better, fixed a few things, too.
                >>
                >> The decorators can now take more than one argument.
                >> The function and arguments lists initialize correctly now.
                >>[/color]
                >Ron:
                >
                >I've followed your attempts to understand decorators with interest, and
                >have seen you engage in conversation with many luminaries of the Python
                >community, so I hesitate at this point to interject my own remarks.[/color]

                I don't mind. It might help me communicate my ideas better.
                [color=blue]
                >In a spirit of helpfulness, however, I have to ask whether your
                >understandin g of decorators is different from mine because you don't
                >understand them or because I don't.[/color]

                Or it's just a communication problem, and we both understand.
                Communicating is not my strongest point. But I am always willing to
                clarify something I say.
                [color=blue]
                >You have several times mentioned the possibility of a decorator taking
                >more than one argument, but in my understanding of decorators this just
                >wouldn't make sense. A decorator should (shouldn't it) take precisely
                >one argument (a function or a method) and return precisely one value (a
                >decorated function or method).
                >[color=green]
                >> It doesn't work with functions with more than one variable. It seems
                >> tuples don't unpack when given to a function as an argument. Any way
                >> to force it?[/color][/color]

                What I was referring to is the case:

                @decorator(x,y, z)

                As being a decorator expression with more than one argument. and not:

                @decorator(x)(y )

                This would give a syntax error if you tried it.
                [color=blue][color=green][color=darkred]
                >>> @d1(1)(2)[/color][/color][/color]
                SyntaxError: invalid syntax

                The problem I had with tuple unpacking had nothing to do with
                decorators. I was referring to a function within the class, and I
                needed to be consistent with my use of tuples as arguments to
                functions and the use of the '*' indicator.
                [color=blue]
                >Do you understand what I mean when I say a decorator should take one
                >function as its argument and it should return a function?
                >
                >regards
                > Steve[/color]

                Hope this clarifies things a bit.

                Cheers,
                Ron


                Comment

                • Scott David Daniels

                  #9
                  Re: Decorator Base Class: Needs improvement.

                  Ron_Adam wrote:[color=blue]
                  > What I was referring to is the case:
                  > @decorator(x,y, z)
                  > As being a decorator expression with more than one argument.[/color]
                  But, we generally say this is a call to a function named decorator
                  that returns a decorator. If you called it:
                  @make_decorator (x,y)
                  def .....
                  We'd be sure we were all on the same page.

                  How about this as an example:

                  def tweakdoc(name):
                  def decorator(funct ion):
                  function.__doc_ _ = 'Tweak(%s) %r' % (name, function.__doc_ _)
                  return function
                  return decorator

                  What is confusing us about what you write is that you are referring to
                  tweakdoc as a decorator, when it is a function returning a decorator.
                  [color=blue]
                  > and not:
                  > @decorator(x)(y )[/color]

                  This is only prevented by syntax (probably a good idea, otherwise
                  we would see some very complicated expressions before function
                  declarations).

                  --Scott David Daniels
                  Scott.Daniels@A cm.Org

                  Comment

                  • Ron_Adam

                    #10
                    Re: Decorator Base Class: Needs improvement.

                    On Tue, 05 Apr 2005 14:32:59 -0700, Scott David Daniels
                    <Scott.Daniels@ Acm.Org> wrote:
                    [color=blue]
                    >Ron_Adam wrote:[color=green]
                    >> What I was referring to is the case:
                    >> @decorator(x,y, z)
                    >> As being a decorator expression with more than one argument.[/color]
                    >But, we generally say this is a call to a function named decorator
                    >that returns a decorator. If you called it:
                    > @make_decorator (x,y)
                    > def .....
                    >We'd be sure we were all on the same page.[/color]

                    Good point, I agree. :)

                    Or alternatively
                    @call_decorator (x,y)

                    Using either one would be good practice.
                    [color=blue]
                    >How about this as an example:
                    >
                    > def tweakdoc(name):
                    > def decorator(funct ion):
                    > function.__doc_ _ = 'Tweak(%s) %r' % (name, function.__doc_ _)
                    > return function
                    > return decorator
                    >
                    >What is confusing us about what you write is that you are referring to
                    >tweakdoc as a decorator, when it is a function returning a decorator.[/color]

                    Bengt Richter is also pointing out there is an inconsistency in
                    Pythons documents in the use of decorator. I've been trying to start
                    referring to the "@___" as the decorator-exression, but that still
                    doesn't quite describe what it does either. Decorarator-caller might
                    be better. Then the decorator-function as the part that defines the
                    decorated-function.

                    Another alternative is to call the entire process what it is,
                    function-wrapping. Then the "@____" statement would be the
                    wrapper-caller, which calls the wrapper-function, which defines the
                    wrapped-function. That's much more descriptive to me.

                    If we do that then we could agree to use decorator as a general term
                    to describe a function as decorated. Meaning it is wrapped and get
                    away from the decorator/decoratoree discussions. But I think that the
                    terminology has been hashed out quite a bit before, so I don't expect
                    it to change. I'll just have to try to be clearer in how I discuss
                    it.
                    [color=blue][color=green]
                    >> and not:
                    >> @decorator(x)(y )[/color]
                    >
                    >This is only prevented by syntax (probably a good idea, otherwise
                    >we would see some very complicated expressions before function
                    >declarations ).
                    >
                    >--Scott David Daniels
                    >Scott.Daniels@ Acm.Org[/color]

                    And this isn't allowed either, although it represents more closely the
                    nesting that takes place when decorator-expressions are stacked.

                    @make_deco1
                    @make_deco2
                    @make_deco3
                    def function1(n):
                    n+=1
                    return n


                    This is allowed, but its not pretty.

                    @make_deco1
                    @ make_deco2
                    @ make_deco3
                    def function1(n):
                    n+=1
                    return n


                    Cheers,
                    Ron


                    Comment

                    • Steve Holden

                      #11
                      Re: Decorator Base Class: Needs improvement.

                      Ron_Adam wrote:[color=blue]
                      > On Tue, 05 Apr 2005 02:55:35 -0400, Steve Holden <steve@holdenwe b.com>
                      > wrote:
                      >
                      >[color=green]
                      >>Ron_Adam wrote:
                      >>[color=darkred]
                      >>>Ok, that post may have a few(dozen?) problems in it. I got glitched
                      >>>by idles not clearing variables between runs, so it worked for me
                      >>>because it was getting values from a previous run.
                      >>>
                      >>>This should work better, fixed a few things, too.
                      >>>
                      >>>The decorators can now take more than one argument.
                      >>>The function and arguments lists initialize correctly now.
                      >>>[/color]
                      >>
                      >>Ron:
                      >>
                      >>I've followed your attempts to understand decorators with interest, and
                      >>have seen you engage in conversation with many luminaries of the Python
                      >>community, so I hesitate at this point to interject my own remarks.[/color]
                      >
                      >
                      > I don't mind. It might help me communicate my ideas better.
                      >
                      >[color=green]
                      >>In a spirit of helpfulness, however, I have to ask whether your
                      >>understandi ng of decorators is different from mine because you don't
                      >>understand them or because I don't.[/color]
                      >
                      >
                      > Or it's just a communication problem, and we both understand.
                      > Communicating is not my strongest point. But I am always willing to
                      > clarify something I say.
                      >
                      >[color=green]
                      >>You have several times mentioned the possibility of a decorator taking
                      >>more than one argument, but in my understanding of decorators this just
                      >>wouldn't make sense. A decorator should (shouldn't it) take precisely
                      >>one argument (a function or a method) and return precisely one value (a
                      >>decorated function or method).
                      >>
                      >>[color=darkred]
                      >>>It doesn't work with functions with more than one variable. It seems
                      >>>tuples don't unpack when given to a function as an argument. Any way
                      >>>to force it?[/color][/color]
                      >
                      >
                      > What I was referring to is the case:
                      >
                      > @decorator(x,y, z)
                      >
                      > As being a decorator expression with more than one argument. and not:
                      >
                      > @decorator(x)(y )
                      >
                      > This would give a syntax error if you tried it.
                      >
                      >[color=green][color=darkred]
                      >>>>@d1(1)(2)[/color][/color]
                      >
                      > SyntaxError: invalid syntax
                      >
                      > The problem I had with tuple unpacking had nothing to do with
                      > decorators. I was referring to a function within the class, and I
                      > needed to be consistent with my use of tuples as arguments to
                      > functions and the use of the '*' indicator.
                      >
                      >[color=green]
                      >>Do you understand what I mean when I say a decorator should take one
                      >>function as its argument and it should return a function?
                      >>
                      >>regards
                      >> Steve[/color]
                      >
                      >
                      > Hope this clarifies things a bit.
                      >
                      > Cheers,
                      > Ron
                      >
                      >[/color]
                      So what you are saying is that you would like to be able to use
                      arbitrarily complex expressions after the :at" sign, as long as they
                      return a decorator? If so, you've been "pronounced " :-)

                      regards
                      Steve
                      --
                      Steve Holden +1 703 861 4237 +1 800 494 3119
                      Holden Web LLC http://www.holdenweb.com/
                      Python Web Programming http://pydish.holdenweb.com/

                      Comment

                      • El Pitonero

                        #12
                        Re: Decorator Base Class: Needs improvement.

                        Scott David Daniels wrote:[color=blue]
                        > Ron_Adam wrote:[color=green]
                        > > ...[/color]
                        >
                        > def tweakdoc(name):
                        > def decorator(funct ion):
                        > function.__doc_ _ = 'Tweak(%s) %r' % (name, function.__doc_ _)
                        > return function
                        > return decorator
                        >
                        > What is confusing us about what you write is that you are referring[/color]
                        to[color=blue]
                        > tweakdoc as a decorator, when it is a function returning a decorator.[/color]

                        "Decorator factory" would be a shorter name for "a function returning a
                        decorator".

                        Comment

                        • Ron_Adam

                          #13
                          Re: Decorator Base Class: Needs improvement.

                          On Tue, 05 Apr 2005 19:38:38 -0400, Steve Holden <steve@holdenwe b.com>
                          wrote:

                          [color=blue][color=green]
                          >>[/color]
                          >So what you are saying is that you would like to be able to use
                          >arbitrarily complex expressions after the :at" sign, as long as they
                          >return a decorator? If so, you've been "pronounced " :-)
                          >
                          >regards
                          > Steve[/color]

                          No not at all, I never said that. But.. ;-)


                          If we get into what I would like, as in my personal wish list, that's
                          a whole other topic. <g>


                          I would have preferred the @ symbol to be used as an inline assert
                          introducer. Which would have allowed us to put debug code anywhere we
                          need. Such as @print total @. Then I can switch on and off
                          debugging statements by setting __debug__ to True or False where ever
                          I need it.

                          And as far as decorators go. I would of preferred a keyword, possibly
                          wrap, with a colon after it. Something like this.

                          def function_name(x ):
                          return x

                          wrap function_name:
                          wrapper1()
                          wrapper2()
                          wrapper3()

                          A wrap command could more directly accomplish the wrapping, so that
                          def statements within def statements aren't needed. (Unless you
                          want'ed too for some reason.)

                          And as far as arbitrary complex expressions go.. Actually I think that
                          it's quite possible to do as it is. ;-)

                          But this is just a few of my current thoughts which may very well
                          change. It's an ever changing list. <g>

                          Cheers,
                          Ron

                          Comment

                          • Greg Ewing

                            #14
                            Re: Decorator Base Class: Needs improvement.

                            Ron_Adam wrote:[color=blue]
                            > I would have preferred the @ symbol to be used as an inline assert
                            > introducer. Which would have allowed us to put debug code anywhere we
                            > need. Such as @print total @.[/color]

                            Don't lose heart, there are still two unused characters
                            left, $ and ?.

                            ? might even be more mnemonic for this purpose, as

                            ?print "foo =", foo

                            has a nice hint of "WT?%$%$ is going on at this point?"
                            to it.

                            --
                            Greg Ewing, Computer Science Dept,
                            University of Canterbury,
                            Christchurch, New Zealand

                            Comment

                            • Ron_Adam

                              #15
                              Re: Decorator Base Class: Needs improvement.

                              On Wed, 06 Apr 2005 16:33:24 +1200, Greg Ewing
                              <greg@cosc.cant erbury.ac.nz> wrote:
                              [color=blue]
                              >Ron_Adam wrote:[color=green]
                              >> I would have preferred the @ symbol to be used as an inline assert
                              >> introducer. Which would have allowed us to put debug code anywhere we
                              >> need. Such as @print total @.[/color]
                              >
                              >Don't lose heart, there are still two unused characters
                              >left, $ and ?.
                              >
                              >? might even be more mnemonic for this purpose, as
                              >
                              > ?print "foo =", foo
                              >
                              >has a nice hint of "WT?%$%$ is going on at this point?"
                              >to it.[/color]

                              LOL, yes, it does. :-)


                              Comment

                              Working...