160032 import from same directory still broken

[hyshai]

Is it still possible to do an import from the same directory?

E.g.

foo
...bar.py
...init.py
baz.py

And in baz.py: from foo import bar

This used to work, though I'm not sure if it was supposed to.

Also, @omz should probably start a new thread for every beta. Instead of having multiple per beta.

[dgelessus]

Yes, that is completely normal Python import behavior. If a folder contains an __init__.py, it is treated as a package and you can import submodules from it. (This of course only works for locations that can be imported from, like the main Script Library or site-packages.)

[ywangd]

It seems that @omz took the dot out from default sys.path. That is why you code does not import. Add following code befor the import and it will work again.

import sys
if '.' not in sys.path:
    sys.path.insert(0, '.')

[omz]

Yes, I accidentally removed "." from the default sys.path, will be back in the next build.

[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!

[hyshai]

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.