(from python-list thread "data attributes override method attributes?")

"9.4. Random Remarks

Data attributes override method attributes with the same name; to avoid accidental name conflicts, which may cause hard-to-find bugs in large programs, it is wise to use some kind of convention that minimizes the chance of conflicts. Possible conventions include capitalizing method names, prefixing data attribute names with a small unique string (perhaps just an underscore), or using verbs for methods and nouns for data attributes."

The first semi-sentence is wrong. Within a class or instance attribute space, later assignments replace earlier ones. Between them, instance attributes (usually) override class attributes. The exceptions are (some? all?) special methods. One suggestion on the thread is to replace the clause with 'Instance attributes override class attributes', as that is the apparent intent, but the exception needs to be noted.

The suggested Method and _data conventions are wrong in that they contradict PEP8 style. Peter Otten suggested that the convention suggestion be shortened to "To avoid name conflicts consider using verbs for methods and nouns for data attributes".

Peter Otten thought the first clause should instead be ""Data attributes and method attributes share the same namespace.", which is also true for a given object. This is a different intepretation of what the original author was getting at. The convention remark applies both within the class namespace and between class and instance namespaces.

Ian Kelly reminds me that instance.__xxx__ is only skipped by the internal machinery and not by direct accesses in user code. In the other hand, docs, official or otherwise, are filled with things like 'len(a) calls a.__len__', so I think something should be said that giving instances special method attributes does not have the effect one might expect.

Well there is http://docs.python.org/reference/datamodel.html#special-method-names (even thought we have a lot of evidence people miss that).

This seems to be a duplicate of #12634.