By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,986 Members | 1,568 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,986 IT Pros & Developers. It's quick & easy.

PEP: Adding decorators for everything

P: n/a
Hi Guys,

This is an idea for a PEP.

How would you guys feel about adding decorator support for
"everything"? Currently, only functions and method are supported.

For example:

@GuardedClass
class Foo:
@Transient
a = 'a transient field, ignored when serializing'

@Const
PI = 22.0 / 7

@TypeSafe(int)
count = 10

...

instead of:
class Foo:
a = Transient('a transient field, ignored when serializing')

PI = Const(22.0 / 7)

count = TypeSafe(int)(10)

...
Foo = GuardedClass(Foo)
I mean, this would pave the way for a declarative style of programming
(in a more intuitive way).

It would also be better if multiple decorators could be written on the
same line. E.g.:
@A @B(x, y) @C
def foo(): ...

instead of
@A
@B(x, y)
@C
def foo(): ...

(The function definition should start on the next line though).
Suggestions, Comments, flames, anybody?
Cheers!

Oct 18 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
> @GuardedClass
class Foo:
The functionality can be done using a meta-class, in a similarily
declarative way.
@Transient
a = 'a transient field, ignored when serializing'

@Const
PI = 22.0 / 7

@TypeSafe(int)
count = 10
These are tricky, as the implicitly change the nature of the values -
they become properties. And the decorator protocol has to change, as the
passed value is obviously not a callable, but a random value. So in the
end, you could simply do something like this:
@Const(3.24)
def PI(self):
pass

with Const basically ignoring its callable-argument and simply returning
a get-only-property. I have to admit that I was tempted to use such a
thingy just the other day. But it is not exactly nice, and using

PI = Const(3.14) as you suggested is even more pleasing.

Additionally, the first @Transient-decorator can't be done that way, as
the decorator protocol doesn't know about the _name_ a thing is bound to
later. And you'd need that to actually set up e.g. __getstate__ operate
properly.

And it doesn't mkae much sense anyway, as "a" is a class variable, not a
instance variable.

So - I'm not very much in favour of these enhancements.

It would also be better if multiple decorators could be written on the
same line. E.g.:
@A @B(x, y) @C
def foo(): ...


That one I like.

Diez
Oct 18 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.