[Python-Dev] Re: Another approach to decorators.

David Abrahams dave at boost-consulting.com
Thu Aug 12 00:38:12 CEST 2004


Michel Pelletier <michel at dialnetwork.com> writes:

>> From: Martin Zarate <mzarate at uoguelph.ca>
>
>> I submit that the most Python solution, that would also be legible (but not 
>> necessarily very pretty) would be to actually make the decorator a bona-fide 
>> block that you nest your class or function into.
>> 
>> remake functor(foo, bar), staticmethod:
>>      def baz():
>>            pass
>> 
>> This concretely shows the relationship of the original define statement to its 
>> wrapper objects.  The principle is simple - the remake block will close with 
>> only one object in its immediate namespace
>
> I like your idea a lot, buy why just one?  Your scheme of making decorators a
> block could be applied to several methods in a class:
>
> class Foo:
>
>   decorate static:
>
>     def static1(blah...):
>         pass
>
>     def static2(blah...):
>         pass
>
> To me, this idea looks more like Python than all the rest, and allows
> you to consolidate related decorated methods and classes.  Nest them to
> apply decorators "aquisition style":
>
>
> class Foo:
>
>   decorate static:
>
>     def static1(blah...):
>         pass
>
>     decorate locksFile:
>
>       def static2andLocks(blah...):  # both decorators appy
>           pass

Wow, Martin Z's idea (using your keyword) really went "thunk" for me.
What decorate does would be very much like what "class" does in some
ways.

I wonder if there's a way, using metaclasses, to get this syntax
today:

    class Foo:

      class d1(static):
        def static1(blah):
          pass

        class d2(locksFile):
          def static2andLocks(blah): # both apply
            pass

for suitably defined "static" and "locksFile" classes?

It's not beautiful, but it would be a good proof of the
generality/implementability of the decorator->class mapping.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



More information about the Python-Dev mailing list