Pythonista 1.5 Import Bug?

TutorialDoctor

Wondering if this has been addressed in the upcoming version.

I am importing a class I made in another script (in the same directory).

When running the current script for the first time, the entire script from the imported file runs.
Also, sometimes methods and member variables cannot be found.
Another thing is that changing the original file is not reflected in the current script (member variables still output the old values).
Finally (so far) the str method does not work sometimes.

Has this been noted before?

ccc

Same solution as http://omz-forums.appspot.com/pythonista/post/5280769899495424

import my_module
reload(my_module)

TutorialDoctor

Okay. Thank you. How would I get this to work with "from"

from my_module import*

ccc

PEP8 and several other Python best practices guides discourage the use of "wildcard imports" (from module import *) but if you must...

import module
from module import *
reload(module)

Phuket2

@ccc, import is tricky for beginners like me. I do the reload(module) etc... Also I have been doing from m import * and from m import foo and import m as xyz.
I think the bigger issue for beginners like me to understand is the name space we are creating. Can get very confusing if you share your code. Also, you can confuse yourself if you are not consistent. I am still not sure the best stradegy. I guess my point is, importing is not that straight fwd. but ts more about understanding the name space. At least that's the way I see it

ccc

Agreed. Listen to this recent podcast http://www.talkpythontome.com/episodes/show/12/deep-dive-into-modules-and-packages to get a good sense for how confusing importing can be for people trying to learn Python. The first link below the podcast is to a YouTube video of a 3 hour (!!) course from the recent PyCon 2015. I highly recommend all of David Beazley's lectures, classes, and books on Python.

Namespaces are one honking great idea -- let's do more of those! is the last line of the Zen of Python.

In my own code, I try to avoid from xxx import altogether because it fails to take advantage of namespaces and instead pollutes the main namespace with variables and functions from outside modules. I try to use import xxx instead because it is easier to read, understand and debug eventhough it is more verbose and might execute slightly slower than code that avoids the dots.

Phuket2

@ccc thanks. I will listen to the podcast. But I think it is a mine field , as usual the more I learn the less I know :) but personally I like the idea of aliasing. Import my_fat_greek_wedding as mfgw. Still have a good name space without being verbose. But another thing that comes into play is The device you are coding on. On my 27inch Mac monitor, is not as important as portrait mode on my iPad.
But I will listen and learn I hope. I am sure it's been said in pythons context before, with great power comes great responsibility.

ccc

Agreed.

import my_big_fat_greek_wedding as mbfgw  # preserves (but renames) the namespace
from my_big_fat_greek_wedding import *    # does not preserve the namespace

Phuket2

Yes. Amazingly Enough I worked it out myself. Although it took me a quite a while. I understand the import * flattens out the name space. And while code will run it may not be running the code you expect. Again, I think it's about some context. The bigger the project the more chance you have to hit these problems. In theory anyway. I am not sure how most people treat Pythonista here, but for me, I try to think about full blown applications. I am no where near that yet. But, that's my direction. That's why I Ask all the questions I do. But there is a lot to understand. And it's a very satisfying, rewarding stimulating journey.

TutorialDoctor

Hmm. I like that we can rename it, and thanks for the replies. I have seen somewhere recently that it is recommended not to use the wildcard import. But I don't like typing the name of the module before every function or variable I use from it. It starts to get redundant.

I do understand how it can be a "bad" thing though

JonB

the preferred approach, by some, is to specifically import what you plan on using from the module. is makes it clear to someone reading your code where MyClass is found, but you still get the benefit of brevity.

from my_module import MyClass

Phuket2

But I guess it's either more complicated or enhanced by _ and __ prefixes about what is imported into the importing module