<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 1, 2014 at 9:29 AM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Aug 1, 2014 at 4:23 PM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
> On Fri, Aug 1, 2014 at 8:29 AM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Aug 1, 2014 at 3:23 PM, Charles R Harris<br>
>> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>> ><br>
>> > On Fri, Aug 1, 2014 at 7:59 AM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Fri, Aug 1, 2014 at 2:54 PM, Charles R Harris<br>
>> >> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>> >><br>
>> >> > Importing inspect looks to take about  500 ns on my machine. Although<br>
>> >> > It<br>
>> >> > is<br>
>> >> > hard to be exact, as I suspect the file is sitting in the file cache.<br>
>> >> > Would<br>
>> >> > probably be slower with hard disks.<br>
>> >><br>
>> >> Or where site-packages is on NFS.<br>
>> >><br>
>> >> > But as the inspect module is already<br>
>> >> > imported elsewhere, the python interpreter should also have it<br>
>> >> > cached.<br>
>> >><br>
>> >> Not on a normal import it's not.<br>
>> >><br>
>> >> >>> import numpy<br>
>> >> >>> import sys<br>
>> >> >>> sys.modules['inspect']<br>
>> >> Traceback (most recent call last):<br>
>> >>   File "<stdin>", line 1, in <module><br>
>> >> KeyError: 'inspect'<br>
>> ><br>
>> > There are two lazy imports of inspect.<br>
>><br>
>> Sure, but get_object_signature() is called unlazily when numpy is<br>
>> imported.<br>
>><br>
>> >> You should feel free to remove whatever parts of `_inspect` are not<br>
>> >> being used and to move the parts that are closer to where they are<br>
>> >> used if you feel compelled to. Please do not replace the current uses<br>
>> >> of `_inspect` with `inspect`.<br>
>> ><br>
>> > It is used in just one place.<br>
>><br>
>> So? That one place is always called whenever numpy is imported.<br>
>><br>
>> > Is importing inspect so much slower than all<br>
>> > the other imports we do?<br>
>><br>
>> Yeah, it's pretty bad.<br>
>><br>
><br>
> The buggy code is for tuple parameter unpacking, a path that is not<br>
> exercised and a feature not in python 3. So... is it safe to excise that<br>
> nasty bit of code,<br>
<br>
"You should feel free to remove whatever parts of `_inspect` are not<br>
</div></div>being used."<br>
<div class=""><br>
> or does Enthought make use of the numpy _inspect module?<br>
<br>
</div>No, of course not. It's _private for a reason.<br>
<div class="im HOEnZb"><br>
> The other (fixable) error is in formatargvalues, which is not in __all__ and<br>
> not used as far as I can tell.<br>
<br></div></blockquote><div><br></div><div>There is a missing import of the disassembler, `dis`, which I suspect would add substantially to the import time. So it looks like the easy path is to excise the code.<br><br></div>
<div>Chuck <br></div></div></div></div>