[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