+ 1
what exactly is the problem in using * . to import all the methods .
3 Antworten
+ 1
If you want to rely on The Zen of Python (later in course)...it's not really explicit, it's less readable, it's ambiguous and not obvious. Imagine wanting to know how much work it will be to replace an import...but now you have to read ALL the code.
That leads to opinions like sloppy programming (if you can't be bothered to show your selections, what's your code like?) and realities like wasted resources. It's unnecessary to read all that into memory just in case you might use it. It's less secure because there's unused code out there (lots of exploits rely on lazily-available code). It's slower if the system has to keep track of the imports, it's harder to debug in memory dumps, etc.
Compiled languages are more forgiving because the linker (etc) reads the whole program, figures out what's actually used and omits the unused stuff. Python can't do that because it's interpreted (as it runs).
+ 1
While studying further I also noted that * is not a wildcard. Instead, it imports whatever methods the module writer managed to include in the module's export list.
If the function you need isn't listed there, Python won't import it with *.
0
It is not good as let's say you import math as m - this will keep you track of were you got functions and help those reading your code say use of module documentation to undestand it better.
Also you may mistake important functions let's take e as an example from math module
You may overrite -say assign variable to e not knowing of the special function and call it to get something not intended
So it is a bad thing I think. especially if your code is to be accessed by others