[issue2029] "python -m pydoc -g" fails

Nick Coghlan added the comment: 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 dir

[issue2029] "python -m pydoc -g" fails

Changes by Nick Coghlan : -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue2029] "python -m pydoc -g" fails

Changes by Nick Coghlan <[EMAIL PROTECTED]>: -- nosy: +ncoghlan ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue2029] "python -m pydoc -g" fails

Changes by Sean Reifschneider <[EMAIL PROTECTED]>: -- assignee: -> ping nosy: +ping priority: -> normal type: -> behavior __ Tracker <[EMAIL PROTECTED]> __ _

[issue2029] "python -m pydoc -g" fails

Guilherme Polo added the comment: 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

[issue2029] "python -m pydoc -g" fails

Amaury Forgeot d'Arc added the comment: 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 pydoc.py is that there is spec

[issue2029] "python -m pydoc -g" fails

New submission from Ben Bass: 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