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

[Nick Coghlan]

On Tue, Nov 1, 2011 at 1:50 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 31 Oct 2011 16:42:00 +0100
> Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>> On Sun, Oct 30, 2011 at 00:18, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > I would like to propose the following PEP for discussion and, if
>> > possible, acceptance. I think the proposal shouldn't be too
>> > controversial (I find it quite simple and straightforward myself :-)).
>>
>> Are these names relative or fully absolute? I.e. I've had problems in
>> the past with unpickling objects that were pickled from a module that
>> was imported using a relative import. Would it be possible to define
>> the qname such that the full path to the name, starting from a
>> sys.path level down, is always used?
>
> The __qname__, by design, doesn't include any module name. To get the
> "full path", you still have to add in the __module__ attribute.
> Solving the problems with relative imports (I'm not sure what they are)
> is another problem which Nick is apparently tackling (?).

PEP 395 (Module Aliasing) is indeed intended to handle the module
naming half of the serialisation issues.

However, relative imports shouldn't cause pickling problems - the
import machinery works out the full name and stores that in __name__
(if there is any case in 3.x where it doesn't, then that's a bug).

That said, *applications* (such as Django, up to and including v1.3)
can corrupt __name__ values by placing package (or subpackage)
directories directly on sys.path. Once an application does that, they
run the risk of getting multiple copies of the same module with
different __name__ values, and serialisation will then depend on
exactly which version of the module was used to create the instances
being serialised.

Django, at least, is going to stop doing that by default in 1.4, but
it's still one of the easiest ways for an application to get itself in
trouble when it comes to serialisation. And, because it's an outright
application bug, there isn't really a lot the interpreter can do to
correct for it (or even warn about it - however, see
http://bugs.python.org/issue13306).

You can also get a similar effect in 2.x by running a file directly
from a package when that file uses implicit relative imports. In that
case, it's really the implicit relative imports that are at fault,
though - there's a reason we killed them in Python 3. If you try the
same thing with explicit relative imports, you at least get a noisy
failure (and, with the module aliasing PEP, the plan is to just "Do
The Right Thing" instead of complaining - there's no ambiguity in what
the user is asking for, we just need to do some additional coding to
actually make it happen).

Cheers,
Nick.

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