Can __iter__ be used as a classmethod?

[Michele Simionato]

Alex Martelli <aleax at aleax.it> wrote in message news:<89G9a.12708$pG1.332485 at news1.tin.it>...

> <snip>
> You've already said you do see the usefulness of static methods.  OK,
> great, so assume static methods ARE in the language -- somebody writes
> a nice package where you can call factories as a = A.fact(1,2,3) AND
> also later b = a.fact(4,5,6) and live happily... *AS LONG AS* the
> factory doesn't need to know exactly what class it's being called on,
> for example because A is not designed to be subclasses, and say that's
> the case initially.  You write client code blissfully unaware, not
> NEEDING to be aware, that A.fact is a static method, and of whether
> some instances of A may override that method in certain cases -- all
> is good in the world.
> 
> But now, second release of the same package, it turns out that in
> some cases it IS important to know exactly on what class the method
> is being called on -- because now you're allowed to subclass A, by
> design, and after "class B(A): pass" you get the certainty that
> b = B.fact(1,2,3) will generate an instance of B and so later will
> b.fact(1,2,3).  Pretty common case, by the way, at least if you
> have any Smalltalk experience/background.
> 
> With classmethods, no problem at all.  Without them, not a good place
> to be in -- each author of a package in such a situation would need
> to perform rather complicated metaclass magic to inject 'fact' in
> the metaclass AND in every instance too... or else reimplement
> classmethods, which is what sensible ones would do.  Over and over
> and over again.

I agree that this is a case where having classmethods can be useful.
Nevertheless, I see this case very rare and I would not see any
problem in implementing classmethods from scratch for this problem
(as Samuele has shown it is very easy).
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. 
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 messages 
because I wanted to make sure that I was not missing an important point 
about their usefulness. It seems my impression was right.

> And that's the argument FOR classmethods -- avoiding multiple and
> redundant reimplementations of the same useful design pattern.  What's
> so problematic with it for you?  Just the fact that you're not
> familiar with it?  I can see no other reason you'd like *static*
> methods but dislike *class* ones, except familiarity!
> 

I was not familiar with staticmethods neither (I do not come from Java or
C++), nevertheless I am disturbed by the confusion between "metamethods"
(regular methods in the metaclass) and classmethods. If Samuele is
right (I have no experience in Smalltalk) class methods in Smalltalk
are actually metamethods. And this make much more sense to me than
Python classmethods. This is a puristic point of view, of course,
and I know that "practicality beats purity" ;)

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
beasts. I mantain that the introduction of classmethods make harder 
the life for newbies without giving a definitive advantage, whereas
on the contrary I would welcome a ternary operator.
Nevertheless I am sure many would think differently ;)
I don't want to enter in such religious issues.

Anyway Alex, thanks for the nice discussion,


                                Michele