This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients benjamin.peterson, brett.cannon, pitrou
Date 2013-06-21.15:01:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP1=2W7+VVkHXg8GMjr4mTGd2kBJpT3fBNjbeJYjqZxD=+C7sA@mail.gmail.com>
In-reply-to <1454941013.104749188.1371823335809.JavaMail.root@zimbra10-e2.priv.proxad.net>
Content
On Fri, Jun 21, 2013 at 10:02 AM, Antoine Pitrou <report@bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > http://bugs.python.org/issue17621 is about trying to finally add a
> > lazy mixin to importlib so people stop asking for it. I have a
> > version already written externally at
> > https://code.google.com/p/importers/source/browse/importers/lazy.py.
> > Part of the trick of making it work is having a way to drop the lazy
> > mixin from the loader MRO for all future uses (which is important
> > for reloads) is to assign __loader__ to super(Mixin, self).
>
> That sounds like a better job for a proxy rather than a mixin.
>

I'm attracted to the idea of making a loader lazy by simply doing something
like ``class LazySourceFileLoader(LazyMixin, SourceFileLoader): ...``. The
key thing is that it doesn't require proxying the constructor in situations
like PathEntryFinder where the finder is going to be making your loader
instance (or at least calling the object). I mean you could override
__call__ to store the arguments and then simply use them when needed to
construct the real loader, but I don't know if that makes the code simpler
without actually coding it up.
History
Date User Action Args
2013-06-21 15:01:38brett.cannonsetrecipients: + brett.cannon, pitrou, benjamin.peterson
2013-06-21 15:01:38brett.cannonlinkissue18275 messages
2013-06-21 15:01:37brett.cannoncreate