160032 import from same directory still broken
Is it still possible to do an import from the same directory?
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.
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
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, '.')
Yes, I accidentally removed "." from the default
sys.path, will be back in the next build.
I originally posted the below in 1.6 thread. The workaround from ywangd worked for me.
Build 160025 bug report.
previously, from within DriverInfo.py,
worked just fine. With the latest beta, I'm getting "ImportError: No module named TripDataA"
This also seems to break the
requestsmodule, fix soon please!
'.'is still not in
Yeah, that's a shame. Just noticed that myself.
Agreed. module in same folder is not findable. Any temp fix, short of moving it to site-packages?
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
just bumping this... seems to have missed the latest beta
Hmm, works for me in the latest beta.
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
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.