Message314759
I guess this confirms our suspicion from issue 33053 that making "-m" no longer track the current working directory had the potential to pose some non-trivial compatibility risks :(
I can reproduce the issue in a 3.7 checkout without a virtual environment:
```
$ ./python -m pydoc itertools
No module named 'ast'
```
There's an odd discrepancy between the behaviour when running pydoc and the behaviour when running runpy, though:
```
$ ./python -im runpy
No module specified for execution
>>> import sys; print(len(sys.path)); print(sys.path)
5
['/home/ncoghlan/devel/py37', '/usr/local/lib/python37.zip', '/home/ncoghlan/devel/py37/Lib', '/home/ncoghlan/devel/py37/build/lib.linux-x86_64-3.7', '/home/ncoghlan/.local/lib/python3.7/site-packages']
>>>
$ ./python -im pydoc itertools
No module named 'ast'
>>> import sys; print(len(sys.path)); print(sys.path)
5
['.', '/home/ncoghlan/devel/py37', '/usr/local/lib/python37.zip', '/home/ncoghlan/devel/py37/build/lib.linux-x86_64-3.7', '/home/ncoghlan/.local/lib/python3.7/site-packages']
>>>
```
The path in the `runpy` case is correct, while the path in the `pydoc` case is missing the expected `Lib` directory (and hence can't import standard library modules), and has had a `.` inserted at the start of `sys.path`. |
|
Date |
User |
Action |
Args |
2018-04-01 04:46:01 | ncoghlan | set | recipients:
+ ncoghlan, nedbat, ned.deily, geoffreyspear |
2018-04-01 04:46:01 | ncoghlan | set | messageid: <1522557961.57.0.467229070634.issue33185@psf.upfronthosting.co.za> |
2018-04-01 04:46:01 | ncoghlan | link | issue33185 messages |
2018-04-01 04:46:00 | ncoghlan | create | |
|