On Fri, Aug 1, 2014 at 8:29 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Aug 1, 2014 at 3:23 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> On Fri, Aug 1, 2014 at 7:59 AM, Robert Kern <robert.kern@gmail.com> wrote:
>> On Fri, Aug 1, 2014 at 2:54 PM, Charles R Harris
>> <charlesr.harris@gmail.com> wrote:
>> > Importing inspect looks to take about  500 ns on my machine. Although It
>> > is
>> > hard to be exact, as I suspect the file is sitting in the file cache.
>> > Would
>> > probably be slower with hard disks.
>> Or where site-packages is on NFS.
>> > But as the inspect module is already
>> > imported elsewhere, the python interpreter should also have it cached.
>> Not on a normal import it's not.
>> >>> import numpy
>> >>> import sys
>> >>> sys.modules['inspect']
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> KeyError: 'inspect'
> There are two lazy imports of inspect.

Sure, but get_object_signature() is called unlazily when numpy is imported.

>> You should feel free to remove whatever parts of `_inspect` are not
>> being used and to move the parts that are closer to where they are
>> used if you feel compelled to. Please do not replace the current uses
>> of `_inspect` with `inspect`.
> It is used in just one place.

So? That one place is always called whenever numpy is imported.

> Is importing inspect so much slower than all
> the other imports we do?

Yeah, it's pretty bad.

The buggy code is for tuple parameter unpacking, a path that is not exercised and a feature not in python 3. So... is it safe to excise that nasty bit of code, or does Enthought make use of the numpy _inspect module?

The other (fixable) error is in formatargvalues, which is not in __all__ and not used as far as I can tell.