[Python-ideas] PEP 3155 - Qualified name for classes and functions

[Nick Coghlan]

On Thu, Nov 10, 2011 at 8:04 AM, Barry Warsaw <barry at python.org> 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.

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__. 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'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?".

For me, it's that last point that rules out ideas like "full name" and
"fully qualified" name - the proposed names deliberately *aren't*
fully qualified in the class and function cases (since they still
leave out the module information, storing that on a separate
attribute).

For the former considerations, I think the differences between
existing __name__ attributes and the new attributes are too subtle and
obscure to ever allow completely intuitive terminology. For classes
and functions, __name__ refers to the name given to the relevant
constructor (either directly or syntactically). This is insufficient
to correctly identify classes and functions that are not defined at
the top level in their respective modules, so the new attribute
addresses that. For modules, __name__ normally refers to the name that
was used to import the module, *unless* it has been altered for some
reason (either to mark the main module or else to redirect
serialisation operations to a public API instead of an implementation
module). The new attribute then allows those alterations of __name__
to take place without losing the information about which module was
actually imported to create the module namespace.

"qname" and "qualified name" are nice, neutral terminology that
suggest something closely related to "name" with being identical. In
all proposed use cases, they preserve information that would otherwise
have been lost.

That said, in earlier drafts of PEP 395 (module aliasing), I did
suggest the term "implementation name". As in the current PEP,
"__name__" would retain its current semantics, while "__impl_name__"
would be what was actually imported when creating the module.

Logic that needed to figure out an objects full name would then look
something like:

    mod_name = obj.__module__
    if mod_name == "__main__":
        mod_name = sys.modules[mod_name].__impl_name__
    full_name = mod_name + "." + obj.__impl_name__

Introspection logic would use either or both, depending on the context
(e.g. pydoc would likely favour using __name__, while inspect would
prefer __impl_name__ for things like getsource()).

It seems to me that "implementation name" would work as a term for
Antoine's PEP as well, since it's about providing enough information
to locate the actual implementation of the class or function relative
to the top level of the module.

The term "implementation name" is also a bit more suggestive of the
intended purpose of these attributes than the completely neutral
"qualified name".

That means my current order of naming preference is:

   - "implementation name" & "__impl_name__"
   - "qualified name" & "__qname__"
   - "qualified name" & "__qualname__"
   - "qualified name" & "__qual_name__"

Cheers,
Nick.

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