On 11/9/11, Nick Coghlan
On Thu, Nov 10, 2011 at 8:04 AM, Barry Warsaw
wrote: Isn't that a problem with the basic terminology then? If you don't know what a "qualified name" is you probably won't know what a "qname" is, and you definitely won't make that connection. I think that's more reason to find the right terminology and spell it out.
I know that a "qualified name" is a special kind of name, and that if I have to worry about it, then I should expect subtle bugs with either false matches, false mismatches, or both. I cannot imagine a more specific definition that is both true and sufficiently simple that I don't have to look it up. But frankly, that seems to be true of the proposed names as well (usually but not always equal to __name__, often but not always sufficient to figure out where the object was defined, etc). The only cognitive grief is about figuring out when I *do* need to use a qname instead of a regular name; I don't see a rule of thumb like "Handles user-generated strings" or "Multiple namespaces are being used".
There may not *be* 'right terminology' for what a qname is going to be, since we're basically inventing the concept to cover some gaps in the meaning of __name__.
And so I suspect there isn't a simple term. (There might be several simple terms that each describe some but not all of the use cases.)
I'm setting the mnemonic bar at "once you know what a Python qname is, is the name suggestive enough to let you remember it?", not at the much higher "if you encounter the Python qname term without knowing what it means, are you going to be able to guess correctly without looking it up?".
I would say that all of __qname__, __q_name__, __qualname__, __qualifiedname__, etc meet that bar, as do __extendedname__ or __impl_name__.
I'm also considering the reverse problem of "if you encounter the Python qname term without knowing what it means, are you going to *think* you know what it means without looking it up and be incorrect?".
I wouldn't, but I'm probably a bad judge on that. -jJ