New submission from Carsten Klein carsten.kl...@axn-software.de:
Scenario:
class deco(object):
def __init__(self, optional = False):
self._optional = optional
def __call__(self, decorated):
decorated.optional = self._optional
return decorated
@deco
class y(object):
pass
Carsten Klein carsten.kl...@axn-software.de added the comment:
will fail decorating the class since y...
actually means that instead of an instance of class y, an instance of the
decorator class will be returned, with y being lost along the way...
--
Santoso Wijaya santoso.wij...@gmail.com added the comment:
I wonder if this is a valid use-case to begin with. The semantic of a
decorator, as I understand it, is very straightforward in that this:
@foo
@bar
class A:
pass
is equivalent to this:
class A:
pass
Carsten Klein carsten.kl...@axn-software.de added the comment:
I think it is, actually, considering
@foo
@bar
class A:
pass
with foo and bar being both decorator classes, the chained call
foo(bar(A))
will return and instance of foo instead of A
With decorator classes
Benjamin Peterson benja...@python.org added the comment:
This is expected; it's the same with functions. Just do @deco().
--
nosy: +benjamin.peterson
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
Carsten Klein carsten.kl...@axn-software.de added the comment:
Ok, looks like a valid work around to me.
However, IMO it is not the same as with decorator functions.
These will be called and will return the correct result,
whereas the decorator class will instead return an instance
of self
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
I concur with Benjamin.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11788
___
Benjamin Peterson benja...@python.org added the comment:
2011/4/6 Carsten Klein rep...@bugs.python.org:
Carsten Klein carsten.kl...@axn-software.de added the comment:
Ok, looks like a valid work around to me.
It's not a workaround. It's the way decorators work.
--
