Can __iter__ be used as a classmethod?
Alex Martelli
aleax at aleax.it
Thu Mar 6 17:23:30 EST 2003
Michele Simionato wrote:
...
> Alternatively, one could have classmethods defined in a module of the
> standard library (and I would like that).
> I don't like the fact that they are in the language.
Well, they're in-between -- they ARE defined in a module of the
standard library... it's just that said module is __builtin__, is all.
> Of course, now there is nothing to do: they are in Python and they will
> stay there. I also use them. I do not discuss that they have some
> convenience, I am saying that their convenience is little. I posted these
Personally I think they're more useful than several other built-ins,
such as (say) apply, buffer, coerce, intern, oct, reduce -- all names
I'd rather have in _other_ library modules and not in __builtin__.
> C++), nevertheless I am disturbed by the confusion between "metamethods"
> (regular methods in the metaclass) and classmethods. If Samuele is
I just don't see that confusion.
> I also was confused by the *syntactic* similarity between staticmethods
> and classmethods: at the beginning I was induced to think that they
> were similar concepts, but actually they are completely different
They're perfectly polymorphic -- they're called in exactly the same
ways, so, in terms of interface a certain class offers to its users,
they ARE extremely similar concepts... the class need not even
document whether a given name is a staticmethod or classmethod --
unless it's specifically designed to support being inherited from
with that method being overridden and called-upwards, a very
specific set of circumstances.
If I want client code to be able to call X.foo() and X().foo(),
it's strictly a matter for ME, as the implementer of class X, if
I want to make foo a staticmethod or a classmethod -- I'll use
the latter if I want foo's code to know what exact class (possibly
a subclass of X, rather than X itself) it's being called on.
That doesn't constituite "completely different" for me -- they're
VERY close in most things that matter (which DOESN'T include
calling type(...) on them and the like -- what Pythonically matters
is essentially signature-based polymorphism).
Alex
More information about the Python-list
mailing list