In article <7da2de5d-dcbc-404e-83cd-0a243374e...@mac.com>, Ronald Oussoren <ronaldousso...@mac.com> wrote:
> On 25 Apr, 2012, at 2:17, Chris Barker wrote: > > > On Tue, Apr 24, 2012 at 4:29 AM, Ronald Oussoren > >> The option "packages" currently always stores the included package outside > >> of site-packages.zip to ensure that data files can be loaded in the old > >> pre-pkgresources way (that is, by opening paths relative to > >> somepackage.__file__). > > > > which is useful, but another thought -- maybe there could be two options: > > > > "packages" and "full_packages" or something -- so one would simple add > > the package to the modulegraph, to catch dynamic imports, and the > > other would do what is done now -- include the whole darn thing. > > > > One other issue with the "whole darn thing" option, is that you get > > the *.py, *.pyc, Na *.pyo files -- so it's maybe three times as big as > > it could be -- I wonder if it's worth cleaning that up. > > Adding "full_packages" for the current behavior and giving "packages" a > semantics that's simular to "modules" would be useful. Please consider retaining the current meaning for the current name and pick a new name for the new meaning (if you can figure one out that makes sense). That would preserve backwards compatibility. Is the inclusion of .pyc and .pyo files a significant problem? If they are not already present then they will be regenerated next time the application is run. Though if some .py files are never loaded then the associated .pyc and .pyo files are wasted space. -- Russell _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
