On Wed, Jul 29, 2009 at 6:44 AM, P.J. Ebyp...@telecommunity.com wrote:
At 10:35 PM 7/28/2009 -0500, Ian Bicking wrote:
On Tue, Jul 28, 2009 at 9:40 PM, P.J. Ebyp...@telecommunity.com wrote:
At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
I can see how this could go quite wrong, but maybe
At 06:52 PM 8/2/2009 +0200, Tarek Ziadé wrote:
On Wed, Jul 29, 2009 at 6:44 AM, P.J. Ebyp...@telecommunity.com wrote:
At 10:35 PM 7/28/2009 -0500, Ian Bicking wrote:
On Tue, Jul 28, 2009 at 9:40 PM, P.J. Ebyp...@telecommunity.com wrote:
At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
I
David Lyon wrote:
Third party libraries are rarely so big that they need to
be compressed to save disk space.. on any of the systems
that i know about anyway..
Hi David. Not just your post but others here are making assumptions on
your own working environment. Yes there are systems you
2009/7/29 Jeff Rush j...@taupro.com:
Hi David. Not just your post but others here are making assumptions on
your own working environment. Yes there are systems you need to save
disk space on, yes there are systems where you care about I/O
performance. These are embedded systems.
Exactly.
On Wed, 29 Jul 2009 01:34:11 -0500, Jeff Rush j...@taupro.com wrote:
Hi David. Not just your post but others here are making assumptions on
your own working environment. Yes there are systems you need to save
disk space on, yes there are systems where you care about I/O
performance. These
On 2009-07-29 16:47, David Lyon wrote:
Anyway, you're kindof biting the hairs on the tail here.. because 3rd
party packages don't impact the size of the whole python installation
that much.
My site-packages directory would like a word with you:
[~]$ cd
On Wed, 29 Jul 2009 09:37:17 +0200, Lennart Regebro rege...@gmail.com wrote:
2009/7/29 Jeff Rush j...@taupro.com:
Hi David. Not just your post but others here are making assumptions on
your own working environment. Yes there are systems you need to save
disk space on, yes there are systems
P.J. Eby wrote:
So the optimum performance tradeoff depends on how many imports you have
*and* how many eggs you have on sys.path. If you have lots of eggs and
few imports, unzipped ones will probably be faster. If you have lots of
eggs and *lots* of imports, zipped ones will probably be
At 01:02 PM 7/29/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
So the optimum performance tradeoff depends on how many imports you
have *and* how many eggs you have on sys.path. If you have lots of
eggs and few imports, unzipped ones will probably be faster. If
you have lots of eggs and
On Tue, Jul 28, 2009 at 8:02 PM, Greg Ewinggreg.ew...@canterbury.ac.nz wrote:
P.J. Eby wrote:
So the optimum performance tradeoff depends on how many imports you have
*and* how many eggs you have on sys.path. If you have lots of eggs and few
imports, unzipped ones will probably be faster.
At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
I can see how this could go quite wrong, but maybe if installers
touch some file in the library directory anytime a package is
installed/reinstalled/removed/etc,
You mean, like, the mtime of the directory itself? ;-)
Really, there's no need
On Tue, Jul 28, 2009 at 9:40 PM, P.J. Ebyp...@telecommunity.com wrote:
At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
I can see how this could go quite wrong, but maybe if installers touch
some file in the library directory anytime a package is
installed/reinstalled/removed/etc,
You mean,
At 10:35 PM 7/28/2009 -0500, Ian Bicking wrote:
On Tue, Jul 28, 2009 at 9:40 PM, P.J. Ebyp...@telecommunity.com wrote:
At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
I can see how this could go quite wrong, but maybe if installers touch
some file in the library directory anytime a package
P.J. Eby wrote:
So the optimum performance tradeoff depends on how many imports you
have *and* how many eggs you have on sys.path.
Spoken like a true master...
and it's imho a real design bludner (blunder)..
sys.path is meant to contain directories for which interpretor
can check for
14 matches
Mail list logo
