<br><br><div class="gmail_quote">On Tue, Jun 28, 2011 at 06:28, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Tue, Jun 28, 2011 at 10:56 PM, Michael Foord<br>
<div class="im"><<a href="mailto:fuzzyman@voidspace.org.uk">fuzzyman@voidspace.org.uk</a>> wrote:<br>
</div><div class="im">> I don't think "data attributes" is clear or precise. Is a property a data<br>
> attribute (well it depends how it is implemented and what it does), is a<br>
> staticmethod a data attribute (no - but then Tres' question - it isn't a<br>
> normal method either so if you define data attribute to mean "all non method<br>
> attributes" then its potentially an open question).<br>
<br>
</div>"callable attributes" and "data attributes" are purely about the API<br>
exposed by the object in question. If we're going for object model<br>
neutral terminology, that's the only view that makes sense. They're<br>
descriptions about how attributes are intended to be *used* that are<br>
completely silent on the question of how they're *implemented*. So<br>
staticmethod would fall into the first group, while property would<br>
fall into the latter.<br></blockquote><div><br>These two terms also have the benefit of being understandable by non Python programmers. Since we can't rely on people read the glossary or any other specific doc before reading the stdlib docs we need to make sure that the terminology that we use can be understood by newbies. Thus I like data and callable attributes since it makes sense even if you come from another programming language since you can easily reason it out.<br>
<br>And now I am done adding my graffiti to the shed.<br><br>-Brett<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
>From an implementation point of view, you carve up the world<br>
differently, so it makes sense to worry about class attributes,<br>
instance attributes, dynamic attributes, etc. (the class vs instance<br>
distinction can also matter to some degree from the usage point of<br>
view, since it affects the scope of any mutable attributes, and the<br>
static vs dynamic distinction can also matter, especially for<br>
introspection purposes).<br>
<br>
This goes back to the original point about all of this being highly<br>
context dependent - how you carve up the set of all attributes is<br>
going to change based on what you're trying to explain (e.g. the<br>
distinction between enforced 'data' descriptors, descriptors that<br>
allow shadowing in the instance dict, class attributes that aren't<br>
descriptors at all, instance attributes and dynamic attributes<br>
retrieved via __getattr__ is another way of dividing them)<br>
<div class="im"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">http://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</div></div></blockquote></div><br>