[Python-3000] packages in the stdlib

[Brett Cannon]

On 6/2/06, Talin <talin at acm.org> wrote:
>
> Ronald Oussoren wrote:
> > On 1-jun-2006, at 17:44, Brett Cannon wrote:
> >>I suppose that's at least partially not an issue at the moment
> >>because you can only add stuff to existing packages through hacks. I
> >>wouldn't touch libraries that inject themselves into existing
> >>packages through .pth hackery because of the juckyness of it [*].
> >>
> >>Yeah, something better than .pth files would be good.
> >
> >
> > There's nothing wrong with .pth files per-se and I use them
> > regularly. The juckyness is in .pth files that contain lines that
> > start with 'import', those can do very scary things such as hot-
> > patching the standard library during python startup. That's something
> > I don't like to see in production code.
>
> Reading over this thread, it seems to me that there is a cross-linkage
> between the "reorganize standard library" task and the "refactor import
> machinery" task - in that much of the arguments about the stdlib names
> seem to hinge on policy decisions as to (a) whether 3rd party libs
> should be allowed to co-mingle with the stdlib modules, and (b) what
> kinds of co-mingling should be allowed ('monkeypatching', et al), and
> (c) what specific import mechanisms should these 3rd-party modules have
> access to in order to do this co-mingling.


Personally, I am not advocating any change in imports nor any mingling of
third-party code with the stdlib.

Moreover, past threads on the topic of import machinery have given me
> the vague sense that there is a lot of accumulated cruft in the way that
> packages are built, distributed, and imported; that a lot of features
> and additions have been made to the various distutils / setuputils /
> import tools in order to solve various problems that have cropped up
> from time to time, and that certain people are rather disatisfied with
> the overal organization (or lack thereof) and inelegance of these
> additions, in particular their lack of a OOWTDI.
>
> I say 'vague sense' because even after reading all these threads, I only
> have a murky idea of what actual *problems* all of these various
> improvements are trying to solve.
>
> Given the cruft-disposal-themed mission statement of Py3000, it seems to
> me that it would make a lot of sense for someone to actually write down
> what all this stuff is actually trying to accomplish; And from there
> perhaps open the discussion as to whether there is some other, more
> sublimely beautiful and obviously simpler way to accomplish the same
> thing.


 Well, for me, the reorganization is to help make finding the module you
want easier, both in the docs and at the interpreter.  This includes
grouping and renaming modules to be more reasonable and follow a consistent
naming scheme.

-Brett

As for the specific cast of .pth files, the general concept is, as far
> as I can tell, is that having to modify environment variables to include
> additional packages sucks; And it particularly sucks on non-Unixy
> platforms such as Windows and Jython. That in itself seems like a
> laudable goal, assuming of course that one has also listed the various
> use cases for why a package wouldn't simply be dumped in 'site-packages'
> with no need to modify anything.
>
> So before starting the work of sketching out broad categories of package
> names, it seems to me that step 1 and 2 are (1) identifying a set of
> requirements for package creation/distribution/location/etc, and (2)
> identify how the design of (1) will impact on the conventions of package
> organization.
>
> -- Talin
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060602/e4067afb/attachment.html