This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: "python -m pydoc -g" fails
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.5
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: ping Nosy List: amaury.forgeotdarc, bpb, georg.brandl, gpolo, ncoghlan, ping
Priority: normal Keywords:

Created on 2008-02-07 12:24 by bpb, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit gpolo, 2008-02-07 22:31
Messages (4)
msg62145 - (view) Author: Ben Bass (bpb) Date: 2008-02-07 12:24
To quickly open a PyDoc browser, I want to be able to run the following:

python -m pydoc -g

This works fine on Python2.4, but fails on 2.5(.1), with following
traceback (tested on both WinXP and Solaris 8, same result):

Traceback (most recent call last):
  File "c:\python25\lib\", line 95, in run_module
    filename, loader, alter_sys)
  File "c:\python25\lib\", line 52, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "c:\python25\lib\", line 32, in _run_code
    exec code in run_globals
  File "c:\python25\lib\", line 2255, in <module>
    if __name__ == '__main__': cli()
  File "c:\python25\lib\", line 2191, in cli
  File "c:\python25\lib\", line 2162, in gui
    gui = GUI(root)
  File "c:\python25\lib\", line 2052, in __init__
    import threading
ImportError: No module named threading

When running -g directly (i.e. without the -m) it works fine,
but this requires knowing the specific location of pydoc library file,
so is less helpful.
msg62149 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-02-07 13:21
There is a difference between "-m" and starting the module directly:
- when running a module, its directory is inserted in front of sys.path.
- with "-m", the empty string '' is inserted in front of sys.path.

The problem with is that there is specific code that modifies
sys.path, and will remove the standard lib from sys.path!
Look for this comment:
   # Scripts don't get the current directory in their path by default.
We could delete three lines there and avoid to remove
dirname(sys.argv[0]) from the path.
msg62184 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-02-07 22:31
I don't see the point of lines below that comment "# Scripts don't get
the current directory in their path by default.". I'm adding a patch
that removes those lines and makes use of pathdirs function instead of
using sys.path in serve function, so you get unique paths and some other
things that pathdirs does. If pathdirs shouldn't be used then it should
be removed as well, because it was not been used anywhere else. It seems
sometime this was changed by mistake.
msg95419 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2009-11-18 10:35
It turns out this problem was breaking pydoc -m completely in Python 3.x
(os.popen was breaking since it couldn't find the subprocess module -
see #7238).

A more robust fix that retains the three lines, but modifies them to
avoid deleting the standard library directory from sys.path when using
'-m' has been applied to the 2.6 and 3.1 maintenance branches as well as
the main development branches for 2.7 and 3.2.
Date User Action Args
2022-04-11 14:56:30adminsetgithub: 46313
2010-12-12 22:41:31r.david.murraylinkissue10688 superseder
2009-11-18 10:35:47ncoghlansetstatus: open -> closed
resolution: duplicate
messages: + msg95419
2009-04-05 22:22:55ncoghlansetnosy: + georg.brandl
2008-11-18 10:43:00ncoghlansetnosy: + ncoghlan
2008-03-18 18:58:29jafosetpriority: normal
assignee: ping
type: behavior
nosy: + ping
2008-02-07 22:31:10gpolosetfiles: +
nosy: + gpolo
messages: + msg62184
2008-02-07 13:21:04amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg62149
2008-02-07 12:24:04bpbcreate