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.
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.
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@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
