[Python-Dev] PEP 318: More examples of decorator use
Phillip J. Eby
pje at telecommunity.com
Tue Apr 6 19:43:08 EDT 2004
At 03:08 PM 4/6/04 -0700, Jim Hugunin wrote:
>*Some examples that I'd like to see in an anti-patterns list
>
>onexit from the PEP. I don't think decorators should have side-effects
>visible outside of the class/function itself. This seems MUCH better
>accomplished with the explicit call to the registration function.
>
>singleton from the PEP. Whenever possible, decorators should return the
>same kind of thing that they are given. This code seems much less clear
>than explicitly creating a singleton instance.
>
>propget, propset, propdel from Edward Loper via Guido. To me, these violate
>the principle of modularity. I much prefer the explicit property
>declaration that puts all of the parts together.
>
> class C(object):
> def getX(self): return self.__x
> def setX(self, x): self.__x = x
> x = property(getX, setX)
Hm. IIRC, Visual Basic defines "property set", "property let", and
"property get" methods in a similar fashion to the propget/propset/propdel
mechanism. What does C# use? Doesn't it have such methods also?
Also, most languages that I've encountered that offer generic functions,
signature overloading, or other similar dispatch mechanisms use variations
of defining the same function/method over and over again, each variation
with the same name, just a different signature, matching pattern, etc.
A bigger problem with propget et al is that they don't follow a sensible
inheritance mechanism. That is, you can't inherit the get method while
overriding the set method. But this is really more a limitation of the way
Python descriptors work, than any issue with decorators.
More information about the Python-Dev
mailing list