[Python-Dev] Empty directory is a namespace? (original) (raw)

PJ Eby pje at telecommunity.com
Sun Jun 24 21:51:31 CEST 2012

On Sun, Jun 24, 2012 at 3:27 PM, "Martin v. Löwis" <martin at v.loewis.de>wrote:

>> In short, it's not worth worrying about, and definitely nothing that >> should cause people to spread an idea that init.py somehow speeds >> things up. > > The best way to avoid people spreading that idea would be to show hard > measurements.

PJE wants people to spread an idea, not to avoid them doing so. In any case, hard measurements might help to spread the idea, here are mine. For the attached project, ec656d79b8ac gives, on my system import time for a namespace package: 113盜 (fastest run, hot caches) import time for a regular package: 128盜 (---- " ------) first-time import of regular package: 1859盜 (due to pyc generation) (remove init.py and pycache to construct the first setup) So namespace packages are indeed faster than regular packages, at least in some cases.

I don't really want to spread the idea that they're faster, either: the exact same benchmark can probably be made to turn out differently if you have, say, a hundred unzipped eggs on sys.path after the benchmark directory. A more realistic benchmark would import more than one module, though... and then it goes back and forth, dueling benchmarks that can always be argued against with a different benchmark measuring different things with other setup conditions.

That's what I meant by "lost in the noise": the outcome of the benchmark depends on which of many potentially-plausible setups and applications you choose to use as your basis for measurement, so it's silly to think that either omitting or including init.py should be done for performance reasons. Do whatever your application needs, because it's not going to make much difference either way in any realistic program. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120624/58ebfc1c/attachment.html>

More information about the Python-Dev mailing list