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`.