On Fri, Aug 1, 2014 at 4:23 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
>
> 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,

"You should feel free to remove whatever parts of `_inspect` are not

being used."

> or does Enthought make use of the numpy _inspect module?

No, of course not. It's _private for a reason.

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