1

I am importing a module in python as this:

from myutils.user_data import *

How do I find out what are the list of methods that I have imported?

I know one workaround from here:

How to list all functions in a Python module?

being:

from inspect import getmembers, isfunction
import myutils.user_data as module_name
functions_list = getmembers(module_name, isfunction)
print(functions_list)

but this would oblige me to use the nomenclature:

module_name.mehtodA() whereas I would like to be able to use the methods as such methodA()

of course I can do:

from myutils.user_data import *
import myutils.user_data as module_name

but this is actually importing two times.

Any idea?

EDIT: Why do I need this? I am creating documentation for a module in a JupyterHub environment (in premises). I create this documentation using notebooks, i.e. anyone interested in finding out the use of a particular .py file (including utility methods) can open the notebook and play around AND the jupyter notebook can be rendered as a web site with voila. In that case I would like to print all the methods included in the particular .py file.
This is also a question that just made me curious. Someone commented you would never import with * a module. Well, why not if you know what you are importing being a few very small methods.

JFerro
  • 3,203
  • 7
  • 35
  • 88
  • You don't do `from myutils.user_data import *` - ever. This will pollute your global namespace and you risk overwriting if you do it with multiple modules. Why do you need to print the function names? If the prefix disturbs you - remove it before printing it. – Patrick Artner Jan 14 '22 at 09:45
  • It's not really clear to me what you need in practice. Do you just want to *print* the newly imported names? Do you want to programmatically *use* the names at some later point? – MisterMiyagi Jan 14 '22 at 09:52
  • Actually if you state two imports of the same module, it is only imported once and not twice. So you could just use the idea, that you mentioned. – Jakob Stark Jan 14 '22 at 10:28
  • @PatrickArtner actually, there are some usecases. For example the `__init__.py` files of packages often include these type of import statements to "collect" all the definitions made in different modules of the package and provide a simple non-hirachical api. So never say never ;) – Jakob Stark Jan 14 '22 at 10:33
  • What good is a non-hirarchical view of a package for functions that are not available if you do not know in which sub module they are located? I dabble only in Python, but I probably would put that in the release pipeline and create the \_\_init\_\_.py either by hand or at "release" time to provide this statically instead of dynamically at runtime from a function call. *shrug* :) – Patrick Artner Jan 14 '22 at 10:46
  • I think people might be over-complicating the assumptions here. This is me, one of the colleagues in a large organisation (no one is here programmer, we use python as a help), that put together a bunch of utility methods in a file user_data.py of a module called moduleX. My intention is just to show to anyone what all utility methods do, and I simply thought I start in the notebook by saying: These are all the methods contained in user_data.py. its not bullet proved, its not perfect, but its a straight forward way. My personal module is in Bitbucket, if a user like it, he pip install it. – JFerro Jan 14 '22 at 11:14
  • On other level sometimes people want to know how things would be done, even if solving the problem in that particular way is not the "professional way" and knowing that this is not the best solution. Somehow people are so opinionated that go and straight forward down vote the question. a pity. – JFerro Jan 14 '22 at 11:18
  • It might be easier to use Python's and Jupyter's already existing help capabilities: The [``help`` and ``pydoc.help`` function](https://docs.python.org/3/library/pydoc.html), as well as [the ``?`` and ``??`` macros](https://ipython.readthedocs.io/en/stable/interactive/python-ipython-diff.html#accessing-help). The Python ecosystem also has substantial tooling for offline (not in a running Python process) documentation, such as [Sphinx](https://www.sphinx-doc.org/en/master/). – MisterMiyagi Jan 14 '22 at 11:26
  • @MisterMiyagi thanks, we know about that. We are talking here to a possibility to serve information to three kind of people. a) coders, b) possible future coders c) people who do not even know what python is (sending a url rendering a notebook with voila). Plus, this is phase 0 of a very tiny project. Sphinx is a mega over killer. And impossible to expect many people to enter stuff in a notebook. They dont even know what a notebook is. – JFerro Jan 14 '22 at 11:30

1 Answers1

4

Generally you are rarely recommended to use the from ... import * style, because it could override local symbols or symbols imported first by other modules.

That beeing said, you could do

symbols_before = dir()
from myutils.user_data import *
symbols_after = dir()
imported_symbols = [s for s in symbols_after if not s in symbols_before]

which stores the freshly imported symbols in the imported_symbols list. Or you could use the fact, that the module is still loaded into sys.modules and do

import sys
from inspect import getmembers, isfunction
from myutils.user_data import *
functions_list = getmembers(sys.modules['myutils.user_data'], isfunction)
print(functions_list)
Jakob Stark
  • 3,346
  • 6
  • 22