Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
160032 import from same directory still broken
-
-
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 orsite-packages
.) -
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.
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"
-
This also seems to break the
requests
module, fix soon please! -
In 160032
'.'
is still not insys.path
-
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.