[Import-SIG] What if namespace imports weren't special?

P.J. Eby pje at telecommunity.com
Mon Jul 11 05:57:06 CEST 2011


At 01:16 PM 7/11/2011 +1000, Nick Coghlan wrote:
>There's also a performance impact on app startup time - currently most
>package imports stop as soon as they hit a matching directory. Under a
>"partitioned by default" scheme, all package imports (including things
>like "logging" and "email" which currently get a hit in the first zip
>file for the standard library) would have to scan the entirety of
>sys.path just in case there are additional shards lying around. For
>large applications, that additional overhead is going to add up.

Darn, I missed that.  That kills the idea pretty much dead right 
there, as it means ALL imports are massively slowed down.  Crap.


>So I don't think implicit partitioning is really going to fly at this
>point. That said, I wouldn't oppose tweaking the partitioned package
>design to eventually support dropping the requirement for explicit
>".pyp(art)" files (i.e. by always placing the directory with
>__init__.py at the head of the list).

Nah, I don't think there's much point to that.

I'm noticing, though, that the more I hear "partitioned package", the 
less I like it, and the more I wish I hadn't proposed it.  ;-)

It's fundamentally wrong, because (e.g.) peak.util is *not* a single 
thing that's been partitioned, *even though* it started out that way.

It's just a bunch of things with a common namespace, and ISTM the 
name *really* ought to reflect that.

Common namespace packages?  Shared namespace packages?  Surname packages?  ;-)



More information about the Import-SIG mailing list