[Python-Dev] Issue10403 - using 'attributes' instead of members in documentation (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Tue Jun 28 17:42:46 CEST 2011

On Tue, Jun 28, 2011 at 7:20 AM, Steven D'Aprano <steve at pearwood.info> wrote:

Michael Foord wrote:

What do you mean by "instances can have methods as instance attributes"? Once you attach a bound method directly to an instance it becomes a slightly different beast I think. (On top of which that is pretty rare behaviour.)

class C: ...     def method(self, x): ...             return x+1 ... c = C() c.method = types.MethodType(lambda self, x: x+101, c) c.method(1) 102 I don't know how rare it is, but it's a useful trick for customising the behaviour of instances. As I see it, there are three dichotomies we sometimes need to make: (1) Instance attributes vs class (shared) attributes. Broadly speaking, whether the attribute is in instance.dict or type(instance).dict. (2) Computed vs non-computed attributes. Attributes which are computed by getattr or via the descriptor protocol (which includes properties) are all computed attributes; everything else is non-computed. (3) Method attributes (methods) vs non-method/data attributes. Broadly speaking, methods are callable, non-method (data) attributes are not.

For terminology, is it important that data attributes are [usually] not callable, or is it that being callable is not relevant to their use as attributes of the class/instance? The same for "methods".

We have precedent for where the the terminology represents an expectation rather than a firm constraint (isabstractmethod).

The three are orthogonal: e.g. a staticmethod is a method by virtue of being callable, computed by virtue of being generated by a descriptor, and a class attribute by virtue of existing in the type dict rather than the instance dict. Strictly speaking, (3) is not truly a dichotomy, since functions and methods are first class-objects in Python. E.g. one may store a function as an attribute with the intention of using it as data rather than as a method. But that's a moderately obscure corner case, and in my opinion it's not worth obscuring the practical distinction between "methods are things you call, data are not" for the sake of it. Leave the functions-as-data case for a footnote.

+1

The "three dichotomies" is a great way to look at it.

-eric

-- Steven

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com

More information about the Python-Dev mailing list