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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4