[IPython-dev] Keyword option for sync_imports and feature request...

MinRK benjaminrk at gmail.com
Fri Feb 3 14:24:27 EST 2012

On Fri, Feb 3, 2012 at 11:03, Ben Edwards <bedwards at cs.unm.edu> wrote:

> Think I sent this yesterday using the wrong email so it got
> rejected(silently?). If it's a duplicate I apologize...
> Two questions. Would it be possible to add a verbose or quiet keyword
> option to sync_imports so it does not print
> "importing %s from %s on engine(s)"
> For each module importing on engines. If this is a worthwhile idea I'll
> make a pull request, with whatever default you guys thinks is reasonable.

Sure, a quiet keyword makes sense.  I would default it to False, because it
is a good indicator of whether the import actually happened, as there are
some circumstances where previous state causes imports to be no-ops, never
actually triggering the import hook necessary to execute the remote import
(I don't remember which, at the moment).

> Also why is sync_imports in the DirectView class but not the
> LoadBalancedView class? I usually use LoadBalancedView, so having to create
> a DirectView instance just for some imports clutters my code ever so
> slightly. Is there a subtle difference I am missing?

If you want an action to happen on particular engines or more than one
engine, DirectView is always thing to use.  If LoadBalancedView had this
method, the import would be load-balanced onto a single engine, and the
only thing you would be guaranteed is that your next apply would *not*
occur on the same engine where you performed the import.

The standard model is to use DirectView for setup, and LoadBalancedView for
submission.  If you use LoadBalancedView for setup, your setup will,
logically enough, be load-balanced, which rarely makes sense.

If you are concerned about clutter and really would only use it for
sync_imports, you need not keep the DV around:

with rc[:].sync_imports(quiet=True):
    import foo
    import bar

If not perhaps we can add the function to the View class so both inherit it?

It was a deliberate choice. I would prefer to keep this sort of
direct-mapped action out of the LB class.  It's the same reason LBView has
no push/pull.


> Ben Edwards
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120203/258e2658/attachment.html>

More information about the IPython-dev mailing list