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