[Import-SIG] What if namespace imports weren't special?
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