160032 import from same directory still broken

[Tizzy]

I originally posted the below in 1.6 thread. The workaround from ywangd worked for me.

Build 160025 bug report.

I have a folder structure /AAAdriver/ inside of which I have DriverInfo.py and TripDataA.py.

previously, from within DriverInfo.py,

"import TripDataA"

worked just fine. With the latest beta, I'm getting "ImportError: No module named TripDataA"

[Webmaster4o]

This also seems to break the requests module, fix soon please!

[userista]

In 160032 '.' is still not in sys.path

[Webmaster4o]

Yeah, that's a shame. Just noticed that myself.

[polymerchm]

Agreed. module in same folder is not findable. Any temp fix, short of moving it to site-packages?

[Webmaster4o]

Yeah, I can use

import sys
if '.' not in sys.path: sys.path.append('.')

At the beginning of a script to fix this. This has to be above your import statement

[JonB]

just bumping this... seems to have missed the latest beta

[omz]

Hmm, works for me in the latest beta.

[Phuket2]

Mine is also working. I also doubled checked to make sure I didn't have a statement in the pythonista_startup.py that was correcting it

[JonB]

oh i see...

>>> '.' in sys.path
False

but the "played" path does get put on top, both for Play button and editor actions.
execfile does not do this, though i guess we were already responsible for setting path using execfile, at least indirectly through chdir.

Editor actions are a little surprising, in that they change sys.path globally. I have not tried this yet, but might that cause unintended consequences for running programs? I.e if there is some dynamic import, running a wrench item would cause that import to break.

I guess the point is, scripts should add their own import folder to sys.path, if they want to be guaranteed to be able to import from that folder later.