[Python-Dev] Empty directory is a namespace?

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