Douglas Alan wrote:
> "Robert Brewer" <> writes:
> > I've been looking through my code and can't find a single case where
> > I declared a classmethod, then called it from an instance, as in the
> > above example. Are there any cases where this is useful?
> Yes, it is useful. I don't know if I've made use of this feature yet
> in Python, but I do know that I was bent out of shape when I realized
> that C++ doesn't support "virtual static functions" (because I would
> have liked to use them.
> These functions are used in a parser that parses text representations
> of objects in the class hierarchy. isLegalFieldTag() is used by the
> parser to hlep determine whether or not a token it has just read is a
> legal token.
For example, whether "hlep" is a legal token?
> The reason why I wanted it to be a static function is
> that whether or not a token is legal does not depend on a particular
> instance -- only on the class of the instance. On the other hand, in
> order to do the parsing, I do need to dispatch based on the class of a
> particular instance.
> I suppose, unlike in C++, in Python I could fetch the class of the
> instance, and then dispatch on that, but that might be a bit
> more cumbersome.
Ah, thanks. By "more cumbersome" are you talking simply about having to
add .__class__ as in:
....or is there more to it?
I would probably implement your example by making isLegalFieldTag a
plain ol' instance method. To take a trivial case:
legal = True
If self hasn't defined "legal" then it is resolved via the class. I'm
sure your logic was more complex, but that's the route I tend to take.
Note that I'm not thinking about barring *all* class access from
instances, just those methods explicitly made 'classmethods', which
expect cls as a first parameter.
"Robert Brewer" <> writes:
> Douglas Alan wrote:
> Ah, thanks. By "more cumbersome" are you talking simply about having to
> add .__class__ as in:
> ...or is there more to it?
I think that should be about it, but I don't really like doing that.
I find it a bit ugly, and if at some point I were to decide that there
is some reason that I do want to use some instance data, then I have
to change my code in more places.
On the other hand, I'm certainly not going to lose any sleep over the
> I would probably implement your example by making isLegalFieldTag a
> plain ol' instance method. To take a trivial case:
> class Tag(object):
> legal = True
> def isLegalFieldTag(self):
> return self.legal
> If self hasn't defined "legal" then it is resolved via the class. I'm
> sure your logic was more complex, but that's the route I tend to take.
I'm not sure I understand what you have in mind. isLegalFieldTag()
takes a string as an argument, and determines whether that string is a
legal "tag" token when parsing textual representations of instances of
that class. In C++, the code had to look something like this (when
translated into Python):
if str == "foo" or str == "bar" or str == "baz": return True
else: return False
isLegalTag = staticmethod(isLegalTag)
f = Foo()
But in Python, I can get rid of vIsLegalTag() altogether, and just do:
If Python were changed as you suggest (modulo "classmethod" vs
"staticmethod") I would have to change the above code. The obvious
way, to me, would be to replace "f." with "f.__class__.".
Now what is the alternative to this that you would do?
> Note that I'm not thinking about barring *all* class access from
> instances, just those methods explicitly made 'classmethods', which
> expect cls as a first parameter.
I'm not sure what your reason is for making a big distinction here
between class methods and static methods. To me, making a big
distinction here would make Python less regular, and consequently more
difficult to learn and understand. Also, it means that if I were to
decide to change isLegalTag from a static method to a class method, I
would have to change more code.