Ok, well, I have a rationale for it: make it possible to get rid of eggs as a mechanism for supporting easy_install. Many people (yourself included) have criticized eggs as an installation mechanism, and this is an alternative that gets rid of .egg files and directories in that case, and most of the need for .pth file usage as well.
How so? I cannot see the need for .egg files or .pth files in the first place. If they exist so that you can import stuff: just install to site-packages, and be done.
The data isn't for them to use to meet their use cases, it's for them to *provide* so that Python tools don't stomp on, uninstall, or otherwise interfere with files installed by the system. In other words, for system packagers, it's a communication from the system to Python, rather than the other way around. Even though the distutils will build the file in the bdist, the system packaging tools would be free to generate their own file listing and signatures and such.
Ok, that's a reasonable requirement. It will be difficult to implement, though, as it will require Linux distributors (in particular) to include the database snippets in their packages. Essentially, one would have to contribute patches to all the distributions (we care about, at least), and then nag the respective maintainers to include these patches.
I probably should have brought this up, in fact, I think I mentioned it in a previous thread, but I would like to see PEP 262 add a way to say "this is a system-installed package, *don't touch*". The idea again is not to do the job of the native packaging system, but rather to ensure that Python-specific tools (e.g. easy_install and friends) do not interfere or conflict with it.
Something like a read-only flag? For those without the read-only flag, the specification should explicitly say what manipulation is allowed. Regards, Martin