[Python-Dev] Great Renaming? What is the goal?
Wed, 29 Mar 2000 06:07:20 -0500
Moshe Zadka wrote:
> On Tue, 28 Mar 2000, Gordon McMillan wrote:
> > What would happen if he (and everyone else) installed
> > themselves *into* my core packages, then I decided I didn't
> > want his stuff? More than likely I'd have to scrub the damn
> > installation and start all over again.
> I think Greg Stein answered that objection, by reminding us that the
> filesystem isn't the only way to set up a package hierarchy.
You mean when Greg said:
>Assuming that you use an archive like those found in my "small" distro or
> Gordon's distro, then this is no problem. The archive simply recognizes
> and maps "text.encoding.macbinary" to its own module.
I don't know what this has to do with it. When we get around
to the 'macbinary' part, we have already established that
'text.encoding' is the parent which should supply 'macbinary'.
> particular, even with Python's current module system, there is no need to
> scrub installations: Python core modules go (under UNIX) in
> /usr/local/lib/python1.5, and 3rd party modules go in
And if there's a /usr/local/lib/python1.5/text/encoding, there's
no way that /usr/local/lib/python1.5/site-
packages/text/encoding will get searched.
I believe you could hack up an importer that did allow this, and
I think you'd be 100% certifiable if you did. Just look at the
Hacking stuff into another package is just as evil as math.pi =
> Anyway, I already expressed my preference of the Perl way, over the Java
> way. For one thing, I don't want to have to register a domain just so I
> could distribute Python code <wink>
I haven't the foggiest what the "Perl way" is; I wouldn't be
surprised if it relied on un-Pythonic sociological factors. I
already said the Java mechanics are silly; uniqueness is what
matters. When Python packages start selling in the four and
five figure range <snort>, then a registry mechanism will likely