Might be out of context here, but IMHO "." shouldn't be assumed to be the current directory anyway. As someone who has ported python to a system where it isn't, these assumptions tend to cause problems. Cheers Chris Sent from my iPhone
On 3 Jun 2021, at 09:31, Robin Becker
wrote: I have a failing test case in 3.10.0b1 for code that uses changes to sys.path and attempts to load unpackaged modules by changing directory and placing '.' into sys.path; the code works as expected in 2.7.18, 3.6-3.10.0a7.
I printed out related variables in the a7 and b1 runs and find that sys.path is identical (modulo version name changes) and that os.getcwd() is as expected and that os.path.isfile('./%s.py' % modulename) is True.
In a7 exec('%s as m', NS) works, but in b1 I get ModuleNotFoundError.
I can fix the problem by changing
sys.path.insert(0,'.')
into
sys.path.insert(0,os.getcwd())
The behaviour of '.' in sys.path has always been slightly mysterious, but is this a real bug and have we just been lucky for 20 years?
I have placed some details here
https://www.reportlab.com/ftp/import-bug-310b1.txt
ReportLab has quite a large codebase and I think it would be hard to get a concise test of this behaviour change. I would be glad if this is an expected change a7-->b1 and if the use of '.' in this way has become somehow wrong.
I do know that during the tests the errant code is executed with different values for the target directory; the first usage seems to succeed. -- Robin Becker _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DE3MDGB2... Code of Conduct: http://python.org/psf/codeofconduct/