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-le...@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/DE3MDGB2JGOJ3X4NWEGJS26BK6PJUPKW/
Code of Conduct: http://python.org/psf/codeofconduct/
