[Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

Nick Coghlan ncoghlan at gmail.com
Tue Jun 28 15:28:28 CEST 2011

On Tue, Jun 28, 2011 at 10:56 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> I don't think "data attributes" is clear or precise. Is a property a data
> attribute (well it depends how it is implemented and what it does), is a
> staticmethod a data attribute (no - but then Tres' question - it isn't a
> normal method either so if you define data attribute to mean "all non method
> attributes" then its potentially an open question).

"callable attributes" and "data attributes" are purely about the API
exposed by the object in question. If we're going for object model
neutral terminology, that's the only view that makes sense. They're
descriptions about how attributes are intended to be *used* that are
completely silent on the question of how they're *implemented*. So
staticmethod would fall into the first group, while property would
fall into the latter.

>From an implementation point of view, you carve up the world
differently, so it makes sense to worry about class attributes,
instance attributes, dynamic attributes, etc. (the class vs instance
distinction can also matter to some degree from the usage point of
view, since it affects the scope of any mutable attributes, and the
static vs dynamic distinction can also matter, especially for
introspection purposes).

This goes back to the original point about all of this being highly
context dependent - how you carve up the set of all attributes is
going to change based on what you're trying to explain (e.g. the
distinction between enforced 'data' descriptors, descriptors that
allow shadowing in the instance dict, class attributes that aren't
descriptors at all, instance attributes and dynamic attributes
retrieved via __getattr__ is another way of dividing them)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list