Decorator Base Class: Needs improvement.

Bengt Richter bokr at oz.net
Wed Apr 6 04:10:22 EDT 2005


On Wed, 06 Apr 2005 02:31:05 GMT, Ron_Adam <radam2 at tampabay.rr.com> wrote:

>On Tue, 05 Apr 2005 19:38:38 -0400, Steve Holden <steve at holdenweb.com>
>wrote:
>
>
>>> 
>>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
>
>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.

I don't understand your seeming fixation with wrappers and wrapping. That's not
the only use for decorators. See Raymond Hettinger's optimizing decorators
in the cookbook for instance. Decorators are something like metaclasses for functions,
with much more general possibilities than wrapping, IMO.

>
>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.)
I think you'll have to show some convincing use cases showing a clear
advantage over current decoration coding if you want converts ;-)

>
>And as far as arbitrary complex expressions go.. Actually I think that
>it's quite possible to do as it is. ;-)
Yes and no. You can always write @deco and refer to an arbitrarily complex
callable deco ..., but the actual @-line expression has to abide by the language grammar,
and that does not allow arbitrary expressions. But it does provide enough rope.
E.g. see my most recent reply to El Pitonero.

>
>But this is just a few of my current thoughts which may very well
>change.  It's an ever changing list. <g>
>
I can see that ;-)

Regards,
Bengt Richter



More information about the Python-list mailing list