> You'd still be able to do that, just as you'd still be able > to use the old method of creating a staticmethod. There > just wouldn't be any special syntax just for staticmethods > analogous to the one I suggested for classmethods. If you are talking about the split descriptor/callable returning decorators, I'm not convinced that having decorators split based on which (one) produce descriptors and which (ones) produce callables is necessarily a good idea. Certainly it is explicit, but so is having it be the /last/ decorator (if we use left-to-right application or first if we use right-to-left application) when we have a single decorator list. > > > I'm not sure I understand. Why not make them module-level functions? > > > > Namespaces my friend, namespaces (I don't know if other people use this, > > but I have on occasion). > > My point was, that in any likely use I can think of for > staticmethods, it wouldn't do any *harm* to use a classmethod > instead. Perhaps not, except in the case when you expect your implementation to document itself (I do most of the time). The use of a classmethod implies something, just as the use of a staticmethod or instancemethod implies other things. Using one for another may be confusing to anyone reading code later. > > def make_all_static(cls): > > for i,j in cls.__dict__.iteritems(): > > if isinstance(j, instancemethod): > > cls.__dict__[i] = staticmethod(j) Oops, I forgot the colon and indentation, it is fixed now. - Josiah
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