Remove numpy/compat/_inspect.py ?
Hi All, The _inspect.py function looks like a numpy version of the python inspect function. ISTR that is was a work around for problems with the early python versions, but that would have been back in 2009. Thoughts? Chuck
The docstring at the beginning of the module is still relevant AFAIK: it was about decreasing import times. See http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
Hi All,
The _inspect.py function looks like a numpy version of the python inspect function. ISTR that is was a work around for problems with the early python versions, but that would have been back in 2009.
Thoughts?
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jul 31, 2014 at 11:46 PM, David Cournapeau <cournape@gmail.com> wrote:
The docstring at the beginning of the module is still relevant AFAIK: it was about decreasing import times. See http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html
On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
The _inspect.py function looks like a numpy version of the python inspect function. ISTR that is was a work around for problems with the early python versions, but that would have been back in 2009.
Thoughts?
It's only used in one function.
def get_object_signature(obj): """ Get the signature from obj """ try: sig = formatargspec(*getargspec(obj)) except TypeError as errmsg: sig = '' # msg = "Unable to retrieve the signature of %s '%s'\n"\ # "(Initial error message: %s)" # warnings.warn(msg % (type(obj), # getattr(obj, '__name__', '???'), # errmsg)) return sig Where a local import would do as well. It also has bugs, so evidently isn't called often ;) Chuck
On Fri, Aug 1, 2014 at 12:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Jul 31, 2014 at 11:46 PM, David Cournapeau <cournape@gmail.com> wrote:
The docstring at the beginning of the module is still relevant AFAIK: it was about decreasing import times. See http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html
On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
The _inspect.py function looks like a numpy version of the python inspect function. ISTR that is was a work around for problems with the early python versions, but that would have been back in 2009.
Thoughts?
It's only used in one function.
Yes, one function that is called at startup, so no, a local import of the stdlib inspect module would not help.
def get_object_signature(obj): """ Get the signature from obj """ try: sig = formatargspec(*getargspec(obj)) except TypeError as errmsg: sig = '' # msg = "Unable to retrieve the signature of %s '%s'\n"\ # "(Initial error message: %s)" # warnings.warn(msg % (type(obj), # getattr(obj, '__name__', '???'), # errmsg)) return sig
Where a local import would do as well. It also has bugs, so evidently isn't called often ;)
What bugs? Any bugs relevant to the objects that get_object_signature() is called with? It does not have to work for anything else but those. -- Robert Kern
On Fri, Aug 1, 2014 at 6:37 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Aug 1, 2014 at 12:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Jul 31, 2014 at 11:46 PM, David Cournapeau <cournape@gmail.com> wrote:
The docstring at the beginning of the module is still relevant AFAIK: it was about decreasing import times. See
On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
The _inspect.py function looks like a numpy version of the python
inspect
function. ISTR that is was a work around for problems with the early
http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html python
versions, but that would have been back in 2009.
Thoughts?
It's only used in one function.
Yes, one function that is called at startup, so no, a local import of the stdlib inspect module would not help.
def get_object_signature(obj): """ Get the signature from obj """ try: sig = formatargspec(*getargspec(obj)) except TypeError as errmsg: sig = '' # msg = "Unable to retrieve the signature of %s '%s'\n"\ # "(Initial error message: %s)" # warnings.warn(msg % (type(obj), # getattr(obj, '__name__', '???'), # errmsg)) return sig
Where a local import would do as well. It also has bugs, so evidently isn't called often ;)
What bugs? Any bugs relevant to the objects that get_object_signature() is called with? It does not have to work for anything else but those.
Undefined variables in getargs. The only two functions used from the module are very small and could simply be brought into `ma/core.py`. The python inspect module is used elsewhere... Chuck
On Fri, Aug 1, 2014 at 7:03 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Fri, Aug 1, 2014 at 6:37 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Aug 1, 2014 at 12:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Jul 31, 2014 at 11:46 PM, David Cournapeau <cournape@gmail.com> wrote:
The docstring at the beginning of the module is still relevant AFAIK:
was about decreasing import times. See
http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html
On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
The _inspect.py function looks like a numpy version of the python
inspect
function. ISTR that is was a work around for problems with the early
it python
versions, but that would have been back in 2009.
Thoughts?
It's only used in one function.
Yes, one function that is called at startup, so no, a local import of the stdlib inspect module would not help.
def get_object_signature(obj): """ Get the signature from obj """ try: sig = formatargspec(*getargspec(obj)) except TypeError as errmsg: sig = '' # msg = "Unable to retrieve the signature of %s '%s'\n"\ # "(Initial error message: %s)" # warnings.warn(msg % (type(obj), # getattr(obj, '__name__', '???'), # errmsg)) return sig
Where a local import would do as well. It also has bugs, so evidently isn't called often ;)
What bugs? Any bugs relevant to the objects that get_object_signature() is called with? It does not have to work for anything else but those.
Undefined variables in getargs. The only two functions used from the module are very small and could simply be brought into `ma/core.py`. The python inspect module is used elsewhere...
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. But as the inspect module is already imported elsewhere, the python interpreter should also have it cached. Chuck
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'
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`. -- Robert Kern
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.
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. Is importing inspect so much slower than all the other imports we do? Chuck
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. -- Robert Kern
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. Chuck
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.
-- Robert Kern
On Fri, Aug 1, 2014 at 9:29 AM, Robert Kern <robert.kern@gmail.com> wrote:
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.
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. Chuck
On Fri, Aug 1, 2014 at 11: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.
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. Is importing inspect so much slower than all the other imports we do?
Yes, please look at the thread I referred to. The custom inspect cut imports by 30 %, I doubt the ratio is much different today. David
On my machine, if I use inspect instead of _inspect in numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99 ms). So the hack certainly still make sense, one just need to fix whatever needs fixing (I am still not sure what's broken for the very specific usecase that code was bundled for). David On Sat, Aug 2, 2014 at 5:11 AM, David Cournapeau <cournape@gmail.com> wrote:
On Fri, Aug 1, 2014 at 11: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.
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. Is importing inspect so much slower than all the other imports we do?
Yes, please look at the thread I referred to. The custom inspect cut imports by 30 %, I doubt the ratio is much different today.
David
On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau <cournape@gmail.com> wrote:
On my machine, if I use inspect instead of _inspect in numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99 ms).
So the hack certainly still make sense, one just need to fix whatever needs fixing (I am still not sure what's broken for the very specific usecase that code was bundled for).
I'm not sure a one time hit of 17 ms is worth fighting for ;) The problems were that both the `string` and `dis` modules were used without importing them. Evidently those code paths were never traversed, so I removed the code using `dis` and raised an error there instead, it was for parsing tuple arguments. The string.join was fixed using the string method. <snip> Chuck
On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau <cournape@gmail.com> wrote:
On my machine, if I use inspect instead of _inspect in numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99 ms).
So the hack certainly still make sense, one just need to fix whatever needs fixing (I am still not sure what's broken for the very specific usecase that code was bundled for).
I'm not sure a one time hit of 17 ms is worth fighting for ;) The problems were that both the `string` and `dis` modules were used without importing them.
Don't fix what ain't broken ;) The 17 ms is not what matters, the % is. People regularly complain about import times, and 25 % increase in import time is significant (the above timing are on my new macbook with SSD and 16 Gb RAM -- figures will easily be 1 order of magnitude worse in common situations with slower computers, slower HDD, NFS, etc...) David
On Fri, Aug 1, 2014 at 8:22 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau <cournape@gmail.com> wrote:
On my machine, if I use inspect instead of _inspect in numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99 ms).
So the hack certainly still make sense, one just need to fix whatever needs fixing (I am still not sure what's broken for the very specific usecase that code was bundled for).
I'm not sure a one time hit of 17 ms is worth fighting for ;) The problems were that both the `string` and `dis` modules were used without importing them.
Don't fix what ain't broken ;)
The 17 ms is not what matters, the % is. People regularly complain about import times, and 25 % increase in import time is significant (the above timing are on my new macbook with SSD and 16 Gb RAM -- figures will easily be 1 order of magnitude worse in common situations with slower computers, slower HDD, NFS, etc...)
Be interesting to compare times. Could you send along the code you used? My machine is similar except it is a desktop with 2 SSDs in raid 0. Chuck
On Sat, Aug 2, 2014 at 11:36 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Fri, Aug 1, 2014 at 8:22 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau <cournape@gmail.com> wrote:
On my machine, if I use inspect instead of _inspect in numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99 ms).
So the hack certainly still make sense, one just need to fix whatever needs fixing (I am still not sure what's broken for the very specific usecase that code was bundled for).
I'm not sure a one time hit of 17 ms is worth fighting for ;) The problems were that both the `string` and `dis` modules were used without importing them.
Don't fix what ain't broken ;)
The 17 ms is not what matters, the % is. People regularly complain about import times, and 25 % increase in import time is significant (the above timing are on my new macbook with SSD and 16 Gb RAM -- figures will easily be 1 order of magnitude worse in common situations with slower computers, slower HDD, NFS, etc...)
Be interesting to compare times. Could you send along the code you used? My machine is similar except it is a desktop with 2 SSDs in raid 0.
I just hacked numpy.lib.__init__ to use inspect instead of _inspect: diff --git a/numpy/compat/__init__.py b/numpy/compat/__init__.py index 5b371f5..57f6d7f 100644 --- a/numpy/compat/__init__.py +++ b/numpy/compat/__init__.py @@ -10,11 +10,11 @@ extensions, which may be included for the following reasons: """ from __future__ import division, absolute_import, print_function -from . import _inspect +import inspect as _inspect from . import py3k -from ._inspect import getargspec, formatargspec +from inspect import getargspec, formatargspec from .py3k import * __all__ = [] -__all__.extend(_inspect.__all__) +__all__.extend(["getargspec", "formatargspec"]) __all__.extend(py3k.__all__) David
On Fri, Aug 1, 2014 at 10:42 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 2, 2014 at 11:36 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Fri, Aug 1, 2014 at 8:22 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau <cournape@gmail.com> wrote:
On my machine, if I use inspect instead of _inspect in numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99 ms).
So the hack certainly still make sense, one just need to fix whatever needs fixing (I am still not sure what's broken for the very specific usecase that code was bundled for).
I'm not sure a one time hit of 17 ms is worth fighting for ;) The problems were that both the `string` and `dis` modules were used without importing them.
Don't fix what ain't broken ;)
The 17 ms is not what matters, the % is. People regularly complain about import times, and 25 % increase in import time is significant (the above timing are on my new macbook with SSD and 16 Gb RAM -- figures will easily be 1 order of magnitude worse in common situations with slower computers, slower HDD, NFS, etc...)
Be interesting to compare times. Could you send along the code you used? My machine is similar except it is a desktop with 2 SSDs in raid 0.
I just hacked numpy.lib.__init__ to use inspect instead of _inspect:
diff --git a/numpy/compat/__init__.py b/numpy/compat/__init__.py index 5b371f5..57f6d7f 100644 --- a/numpy/compat/__init__.py +++ b/numpy/compat/__init__.py @@ -10,11 +10,11 @@ extensions, which may be included for the following reasons: """ from __future__ import division, absolute_import, print_function
-from . import _inspect +import inspect as _inspect from . import py3k -from ._inspect import getargspec, formatargspec +from inspect import getargspec, formatargspec from .py3k import *
__all__ = [] -__all__.extend(_inspect.__all__) +__all__.extend(["getargspec", "formatargspec"]) __all__.extend(py3k.__all__)
I was more interested in how you timed it. Chuck
participants (3)
-
Charles R Harris -
David Cournapeau -
Robert Kern