On Mon, Mar 17, 2008 at 08:19:11PM +0000, Paul Moore wrote: > On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > That leaves MAL, whose objections to PEP 365 centered on the API (he > > said he was "+1 on the concepts being added to the stdlib, -1 on > > adding the module in its current state"). Among other concerns, he > > wanted pkg_resources to be split into pkgutil and a new "egglib" > > module. I don't have a problem with this in principle, if there were > > a pkg_resources module that reconstituted the merged API. (But there > > are some practical problems with that approach, such as trying to > > split namespace package support between two theoretically-unrelated > > modules.) > > I would personally like to see such a separation. As one of the > authors of PEP 302 (well, the documentation - Just did all of the > implementation) I have an interest in strengthening the standard > library's support for transparent use of PEP 302 importers. To that > end, I would like to see such functions as > pkg_resources.resource_string() standardised.
+1 for something like this in the stdlib.
os.path.join(os.path.dirname(__file__), 'foo') just has too many
problems.
Could namespace package support be split into a set of hooks in the
stdlib and a concrete implementation in setuptools? Isn't that the way
zip importers were originally done?
Marius Gedminas
--
As an aside, UPnP's implementation (which features SOAP, HTTP over
multicast/broadcast UDP, and extremely odd XML) is a must-read for fans of
unnatural and baroque network protocols.
-- Anthony Baxter
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
