[Python-3000] packages in the stdlib

[Talin]

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