On 28/06/2011 12:04, Fred Drake wrote: > On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord > <fuzzyman at voidspace.org.uk> wrote: >> Added to which there are other descriptors, notably property, that are not >> directly callable but are not provided as normal "data attributes" (although >> the access syntax is the same). Properties are much closer to methods as >> they are implemented on the class and fetched via the descriptor protocol. >> Instead of "data attributes" I prefer the term "instance attributes" >> although that doesn't include "class attributes" (or more precisely it >> doesn't cover "class attributes that aren't descriptors"). > Given the availability of __getattr__ and __getattribute__, I consider > properties an implementation detail for some attributes. The fact that > Python code is called on access is only marginally interesting. > Well, they're *usually* implemented as methods and backed by a real instance attribute. Usually (but not always) it makes more sense (IME) to group them with methods. The fact that they're *accessed* as an attribute is the uninteresting detail. __getattr__ and __getattribute__ are interesting - they allow you to use attribute access syntax for things that *aren't* attributes. I appreciate the fact that the Python data-model means methods are just object attributes, but they're not *instance attributes* and sometimes you need to make a distinction. (And yes it is helpful if the standard terminology leads people into a better understanding of the Python data model, but that still doesn't change the need on occasion for terminology that doesn't need to be explained whenever it is used.) Given that how even methods are to be described depends on the context (if you're fetching bound methods as objects then it makes perfect sense to just talk about them as attributes) it doesn't seem an area amenable to one-size-fits-all terminology. >> The problem with "data attributes" is that it doesn't mean *anything*, which >> I suppose is useful for invented terminology, but it means it doesn't convey >> anything precise to those who haven't heard the term before. If it becomes >> widely used then that changes I guess. I'd still normally just use >> "attributes" though... > I'd read "data attributes" the same as "non-method attributes". For readers, > calling them "attributes" is typically sufficient. It's rare to need to > distinguish them from methods. Yeah, this is all a grand bikeshed. I'm not sure I would understand "data attributes" unless it was clear from the context. I would wonder what qualifies something as "data". It is an interesting question what terminology we should use in the documentation if we need to distinguish them, but I think that is still wandering away from the original question that was posed. All the best, Michael > > -Fred > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4