I agree that the use case is probably rare.

I agree that to someone intimately familiar with the "self-consistent rules" of Python, the correctness of the C.f() approach is probably obvious.

However, your documentation says:

    Static methods in Python are similar to those found in Java or C++.

I feel that it's a mistake to purposefully avoid saying where that similarity ends.  In those languages (and in many others), fully qualified function calls from within the same class are redundant and border on "code smell".  We agree that this aspect of Python is not mentioned in the documentation, and we disagree on whether it should be.  For myself, even in the 7 years and thousands of lines of Python since I opened this issue, I still don't find it intuitive or obvious that a method would need to know the name of the class that contains it.  That doesn't make the language "wrong" in any way; it makes the documentation incomplete for not addressing it.  

The __class__.f() usage in Python 3 seems excellent.  If that's the preferred way to do it, then that might be a way to approach the documentation.  "To call one static method from another within the same class, as of Python 3 you may use __class__.f() instead of C.f().  For Python 2.x, you must still use the name of the class itself, C.f(), as if you were calling from outside the class."  (My wording is still less than ideal, but you get the idea.)