> It's about staticmethods. I was writing a class, and its > pretty-printing method got a function for converting a value to a > string as an argument. I wanted to supply a default function. I > thought that it should be in the namespace of the class, since its > main use lies there. So I made it a staticmethod. > > But - alas! After I declared the function a staticmethod, I couldn't > make it a default argument for the method, since there's nothing to do > with staticmethod instances. > > The minor solution for this is to make staticmethod objects callable. > This would solve my problem. But I suggest a further step: I suggest > that if this is done, it would be nice if classname.staticmethodname > would return the classmethod instance, instead of the function itself. > I know that this things seems to contradict Guido's proposal, since he > suggests to return the function instead of a strange object, and I > suggest to return a strange object instead of a function. But this is > not true; Both are according to the idea that class attributes should > be, when possible, the same objects that were created when defining > the class. This is more consistent with the behaviour of modules > (module attributes are the objects that were created when the code was > run), and is more consistent with the general convention, that running > A = B > causes > A == B > to be true. Currently, Class.func = staticmethod(func), and Class.func > = func, don't behave by this rule. If the suggestions are accepted, > both will.
Well, given that attribute assignment can be overloaded, you can't depend on that requirement all the time. > I just think it's simpler and cleaner that way. Just making > staticmethods callable would solve my practical problem too. The use case is fairly uncommon (though not invalid!), and making staticmethod callable would add more code without much benefits. I recommend that you work around it by setting the default to None and substituting the real default in the function. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
