[Import-SIG] Namespace Packages resolution
ironfroggy at gmail.com
Tue Mar 13 04:51:30 CET 2012
On Mar 12, 2012 11:18 PM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> On Tue, Mar 13, 2012 at 12:30 PM, Carl Meyer <carl at oddbird.net> wrote:
> > If this is indeed the proposed algorithm, then I think the "backwards
> > compatibility" item on Nick's list of objections is unfounded. The new
> > behavior will only occur in situations that would previously have
> > resulted in an ImportError.
> The complaint that it's a complicated hack that is only necessary to
> cope with the lack of explicit package markers still stands, though.
> (But yes, I was definitely going off the parenthetical comment rather
> than the earlier description that contradicted that part).
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
I hate to have left before the sprints and not be around to chat about this!
I maintain a not-unpopular library, straight.plugin, which uses namespace
packages to collect and load various types of plugins as or from the
modules in that namespace. So, I'm interested in the impact this will have
on my little project.
At the first posting of these objections, it seemed to indicate these
implicit packages would break my system for plugins. with the
clarifications since made, out seems it would make this and similar plugin
loaders easier to use, lowering the barrier for less experienced developers
who do bit understand the package system.
Thus, FWIW, if the changes proposed would only alter the namespace package
writing by simplifying the process and excluding the boilerplate
__init__.py, this humble plugin library author gives two thumbs up.
> Import-SIG mailing list
> Import-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG