<br><br><div class="gmail_quote">On Fri, Oct 9, 2009 at 11:55 AM, Robert Kern <span dir="ltr">&lt;<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 2009-10-09 13:00 PM, Brian Granger wrote:<br>
<br>
&gt; * To be in IPython.extensions or IPython.config.profile a module has to<br>
&gt; satisfy a few things:<br>
&gt;<br>
&gt; - There has to be willingness amongst the core IPython developers to<br>
&gt; maintain the code.<br>
&gt; - The code needs to be reviewed (tests, docs, etc.)<br>
&gt; - If the code should be in IPython.core, it shouldn&#39;t be in extensions.<br>
&gt; - If an extension/profile can be distributed as a third party package,<br>
&gt; it should be.  Thus,<br>
&gt; the custom completer for enthough.traits should ship with<br>
&gt; enthought.traits.  Things related<br>
&gt; to numpy should ship with numpy.<br>
<br></div></blockquote><div><br>This is an important point and I want to understand the issues and fix things now...<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>There is one issue with this. You want to be able to configure some things for a<br>
particular package in your configuration files at startup, but not actually<br>
import the package, which may be expensive. </blockquote><div><br>With the changes I have in my local branch this is possible.  You simply enter the config<br>information in the config files, but don&#39;t list the extensions in the config<br>
field of the extensions that should be loaded at startup.  Then you have a number of<br>choices for loading the extension:<br><br>get_ipython().load_extension(&#39;package.myextension&#39;)<br><br>or <br><br>%load_ext package.myextension<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">With care, many of the<br>
package-specific extensions can be written in such a way as to be enabled at<br>
startup but not import the package until it absolutely must (in which case the<br>
user has probably already imported it himself). For example, I submitted a patch<br>
to ipy_traits_completer that replace isinstance(obj, HasTraits) checks for one<br>
that looked for superclasses named &quot;HasTraits&quot; before import HasTraits and doing<br>
the real isinstance() check.<br>
<br></blockquote><div><br>The question of a lazy loading of an extension is a good point.  For now, let&#39;s pretend<br>that an extension can be imported/loaded without any side effects (it is not in a package<br>that has an __init__ that imports everything).  Then lazy importing is easy right?<br>
You can just make sure that the package (traits/numpy/etc) isn&#39;t imported when the<br>extension is imported, but later, when the extension is first used.<br><br>But don&#39;t you think that if someone has explicitly enabled a numpy based extension,<br>
it is because they are using numpy (so importing it at startup would happen anyways).<br><br>If a user didn&#39;t want to *always* have the numpy extension loaded, they could<br>simple maintain a numpy profile that loaded numpy.<br>
<br>But if you really need lazy importing, I think it is possible still...<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Now, it wouldn&#39;t be too oppressive to put ipy_traits_completer into<br>
enthought.traits because we keep the __init__s clear (except for namespace<br>
package stuff, natch). But one couldn&#39;t put IPython support code into numpy<br>
without needing to import numpy itself to activate it in the configuration.<br>
<br></blockquote><div><br>Yes, for packages that have lots of things in __init__, this is a problem.  <br><br>For something as common as numpy, I think shipping it in IPython.extensions<br>
may make sense.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It might be worth having an ipy_extensions package distributed separately from<br>
IPython that collects these extensions to reduce the burden on the IPython<br>
developers and the quality disparity with the rest of code.<br></blockquote><div><br>  This is a good point.  I have envisioned something like a meta-project on launchpad,<br>similar to this for Twisted related projects:<br>
<br><a href="https://launchpad.net/tx">https://launchpad.net/tx</a><br><br>That way the development of all the extensions/profiles can proceed independently.<br>I could even imagine that other things might eventually be moved outside the core<br>
to a place like this (GUI frontends, etc.)<br><br>Cheers,<br><br>Brian<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
--<br>
Robert Kern<br>
<br>
&quot;I have come to believe that the whole world is an enigma, a harmless enigma<br>
  that is made terrible by our own mad attempt to interpret it as though it had<br>
  an underlying truth.&quot;<br>
   -- Umberto Eco<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>