Hi, there there seems to be something weird going on when trying to access help in the following way
import scipy help("scipy.linalg") Help on instance of _ModuleLoader in scipy:
scipy.linalg = <module 'scipy.linalg' from '/opt/python/lib/pyt... e-packages/scipy/linalg/__init__.pyc' [imported]> Doing another
help("scipy.linalg")
one gets the expected help. I'd guess that this somehow has to to with the lazy importer of scipy. But maybe there is a workaround? Many thanks in advance, Arnd
On Fri, 27 Feb 2004, Arnd Baecker wrote:
there there seems to be something weird going on when trying to access help in the following way
import scipy help("scipy.linalg") Help on instance of _ModuleLoader in scipy:
scipy.linalg = <module 'scipy.linalg' from '/opt/python/lib/pyt... e-packages/scipy/linalg/__init__.pyc' [imported]>
Doing another
help("scipy.linalg")
one gets the expected help.
I'd guess that this somehow has to to with the lazy importer of scipy. But maybe there is a workaround?
I get similar behaviour when using ipython. But in a traditional Python prompt
import scipy help("scipy.linalg")
I get expected help. This is because ppimport redefines built-in help:
help Type help () for interactive help, or help (object) for help about object. help.__module__ 'scipy_base.ppimport'
So, for some reasons, in my case when using ipython, redefined help is not effective and probably because help is referenced in ipython before importing scipy. It seems that you are not using ipython, so, what is the contents of your PYTHONSTARTUP? Pearu
On Fri, 27 Feb 2004, Pearu Peterson wrote:
On Fri, 27 Feb 2004, Arnd Baecker wrote:
there there seems to be something weird going on when trying to access help in the following way
import scipy help("scipy.linalg") Help on instance of _ModuleLoader in scipy:
scipy.linalg = <module 'scipy.linalg' from '/opt/python/lib/pyt... e-packages/scipy/linalg/__init__.pyc' [imported]>
Doing another
help("scipy.linalg")
one gets the expected help.
I'd guess that this somehow has to to with the lazy importer of scipy. But maybe there is a workaround?
I get similar behaviour when using ipython.
Well, that's where I first saw this as well (honestly, I always use ipython ;-) As I also see this with the normal python prompt I thought it is un-related to ipython.
But in a traditional Python prompt
import scipy help("scipy.linalg")
I get expected help. This is because ppimport redefines built-in help:
help Type help () for interactive help, or help (object) for help about object. help.__module__ 'scipy_base.ppimport'
I get precisely the same output ((to be clear here: apart from that help("scipy.linalg") gives the above _ModuleLoader message on the first invocation, and only the second time I get the expected help.)) If this matters: - scipy.__version__: '0.2.1_253.3701' - Python: 2.3.3
So, for some reasons, in my case when using ipython, redefined help is not effective and probably because help is referenced in ipython before importing scipy.
With IPython 0.5.1.cvs I get the same as described above, however with In [4]: help.__module__ Out[4]: 'site'
It seems that you are not using ipython, so, what is the contents of your PYTHONSTARTUP?
no contents, I don't use it. What further tests could I do solve this issue ? (maybe we need further tests by other users to find the origin?) Many thanks, Arnd P.S.: just another "screen shot": Python 2.3.3 (#1, Feb 3 2004, 22:05:11) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
help.__module__ 'site' import scipy help.__module__ 'scipy_base.ppimport' help("scipy.linalg") Help on instance of _ModuleLoader in scipy:
scipy.linalg = <module 'scipy.linalg' from '/opt/python/lib/pyt...e-packages/sci py/linalg/__init__.pyc' [imported]>
help("scipy.linalg")
Help on package scipy.linalg in scipy: NAME scipy.linalg FILE [..]
Hi, On Fri, 27 Feb 2004, Arnd Baecker wrote:
On Fri, 27 Feb 2004, Pearu Peterson wrote:
On Fri, 27 Feb 2004, Arnd Baecker wrote:
there there seems to be something weird going on when trying to access help in the following way
import scipy help("scipy.linalg") Help on instance of _ModuleLoader in scipy:
scipy.linalg = <module 'scipy.linalg' from '/opt/python/lib/pyt... e-packages/scipy/linalg/__init__.pyc' [imported]>
Doing another
help("scipy.linalg")
one gets the expected help.
But in a traditional Python prompt
import scipy help("scipy.linalg")
I get expected help. This is because ppimport redefines built-in help:
help Type help () for interactive help, or help (object) for help about object. help.__module__ 'scipy_base.ppimport'
import scipy Traceback (most recent call last): [...] from basic import * File "/opt/python/lib/python2.3/site-packages/scipy/special/basic.py",
we have had a further look into this and the status is as follows - setting postpone_import = 0 in (for example) scipy/xplt/info_xplt.py gives line 10, in ? from scipy import factorial ImportError: cannot import name factorial We thought that setting `postpone_import = 0` means that the import of this module is not postponed so that the doc string should be available from the first call to help("scipy.xplt"). Is this idea/approach just wrong ? - We found that for >>> import scipy >>> help(scipy.xplt) the correct documentation is visible already on the first invokation of help. (In contrast to >>> import scipy >>> help("scipy.xplt") ) Using the source to ppimport.py this is clear as in the first case the module is imported (in class _Helper) before calling the original _pydoc.help. However, for a string there is no corresponding "ppimport" attribute and it gets passed directly to _pydoc.help Just to be sure that we understand things correctly: Is it true that the actual import in the second case, i.e. help("scipy.xplt"), is done when __repr__ from the class _ModuleLoader is called via the "normal" pydoc? And by this the doc string is available for the following help("scipy.xplt"), right? To us it seems to boil down to the question if there is a good way to import the corresponding module for the request help("scipy.xplt") in a similar way as it is done for help(scipy.xplt)? (Changing __repr__ to also output the docstring sounds like a horrible hack ..., i.e. there should be a better way) Many thanks in advance for any suggestions/pointers/..., Ulf Lorenz, Arnd Baecker
On Mon, 1 Mar 2004, Arnd Baecker wrote:
we have had a further look into this and the status is as follows
import scipy Traceback (most recent call last): [...] from basic import * File "/opt/python/lib/python2.3/site-packages/scipy/special/basic.py",
- setting postpone_import = 0 in (for example) scipy/xplt/info_xplt.py gives line 10, in ? from scipy import factorial ImportError: cannot import name factorial
We thought that setting `postpone_import = 0` means that the import of this module is not postponed so that the doc string should be available from the first call to help("scipy.xplt"). Is this idea/approach just wrong ?
No, setting `postpone_import = 0` should have worked. I look into it.. Ahh, I see, it is a chicken and egg problem..
- We found that for >>> import scipy >>> help(scipy.xplt) the correct documentation is visible already on the first invokation of help. (In contrast to >>> import scipy >>> help("scipy.xplt") )
Using the source to ppimport.py this is clear as in the first case the module is imported (in class _Helper) before calling the original _pydoc.help. However, for a string there is no corresponding "ppimport" attribute and it gets passed directly to _pydoc.help
Right.
Just to be sure that we understand things correctly: Is it true that the actual import in the second case, i.e. help("scipy.xplt"), is done when __repr__ from the class _ModuleLoader is called via the "normal" pydoc? And by this the doc string is available for the following help("scipy.xplt"), right?
To us it seems to boil down to the question if there is a good way to import the corresponding module for the request help("scipy.xplt") in a similar way as it is done for help(scipy.xplt)? (Changing __repr__ to also output the docstring sounds like a horrible hack ..., i.e. there should be a better way)
I have fixed this issue in CVS using different and I think more robust approach: `import scipy_base` will redefine help.__class__.__call__ method to support ppimport'ed modules. Now `help` works as expected for all of the following usage cases: help(scipy.linalg) help("scipy.linalg") exec 'help("scipy.linalg")' etc I have tested this on Python 2.3.3 only though. Regards, Pearu
Hi Pearu, On Mon, 1 Mar 2004, Pearu Peterson wrote: [...]
I have fixed this issue in CVS using different and I think more robust approach: `import scipy_base` will redefine help.__class__.__call__ method to support ppimport'ed modules. Now `help` works as expected for all of the following usage cases:
help(scipy.linalg) help("scipy.linalg") exec 'help("scipy.linalg")' etc
I have tested this on Python 2.3.3 only though.
Great - _many_ thanks for the fix! Both >>> import scipy >>> help("scipy.xplt") and In [1]: import scipy In [2]: help("scipy.xplt") also work for me (I am also 2.3.3 as well). There seems to be one case where I still see the module loader when requesting help: Python 2.3.3 (#1, Feb 3 2004, 22:05:11) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
help("scipy.linalg")
I.e., no `import scipy` (or similar) has been done before. I am not sure how important this case is (eg. for doc-extracting tools ?). Concerning ipython: - for the help itself it seems to work - for TAB completion one (sometimes) has to press TAB twice, for example: In [1]: import scipy In [2]: scipy.xplt. # pressing TAB here gives: scipy.xplt.__class__ scipy.xplt.__name__ scipy.xplt.__doc__ scipy.xplt.__repr__ scipy.xplt.__file__ scipy.xplt.__setattr__ scipy.xplt.__getattr__ scipy.xplt.__str__ scipy.xplt.__init__ scipy.xplt._ppimport_importer scipy.xplt.__module__ scipy.xplt.test In [2]: scipy.xplt. # pressing TAB here then gives the # full list (omitted here ;-) I am not sure what to do here. Anyway, this is only here for completeness and should better be discussed on the ipython mailing list (I know, Fernando, you are super-busy right now, so we will try to have a quick look at that tomorrow). Best, Arnd
Pearu Peterson wrote:
So, for some reasons, in my case when using ipython, redefined help is not effective and probably because help is referenced in ipython before importing scipy. It seems that you are not using ipython, so, what is the contents of your PYTHONSTARTUP?
Indeed, ipython imports help upon starting. So by the time scipy tries to modify things, the help ipython sees is already the default one. I've noticed in general that, because of the lazy import mechanisms of scipy, often I need to do things like hitting tab twice, at least the first time I try them. I realize the rationale for the lazy import system, so I don't know if this is something which can even be fixed at all. But if there are any changes which ipython can make to improve the situation, and someone can at least point me in the right direction, I'll gladly give it a try. Regards, f.
participants (3)
-
Arnd Baecker -
Fernando Perez -
Pearu Peterson