3 ms·

Why?

• VMG 15y ago
  pollution of the global name space
  • tantalor 15y ago
    Irrelevant for shell-style scripts because they are entry points, not included from other modules. --And its not a "global" name space, its just the namespace of your script.--
    • viraptor 15y ago
      It's a global namespace in your script. That's what it's called, I believe and it's available via globals().
      • tantalor 15y ago
        Aye, they are added to "current scope's global variables", thank you for correcting.
• dman 15y ago
  Off the top of my head a) Nothing prevents the writer of the module you are importing from overriding symbols that you expect b) In many cases increased load times. c) Irrelevant symbols present in scope when debugging d) Makes the order of import statements important, because potentially different modules might be providing the same variable name
• rytis 15y ago
  because this might mess up your script by either overwriting something that's already defined, or you might accidentally overwrite something that is 'hidden' behind the '* '. somewhat naive example: >>> time = 'blah' >>> time 'blah' >>> from datetime import * >>> time <type 'datetime.time'> >>>
• ulope 15y ago
  Because it leads to namespace pollution and hard-to-track-down bugs. It's especially bad in this case where adding an executable in the system can suddenly shadow any built-in name (e.g. imagine someone adds a "print" or "sys" executable).
  • gbog 15y ago
    Refactoring is also made much harder with import * if you have cascading modules. I have a pylint hook forbidding these before committing to our hg repo
• andylei 15y ago
  makes references ambiguous to anyone but the interpreter let's say you have from a import foo from b import * what does 'foo' refer to? 'b' could contain 'foo', which would overwrite your previous reference to 'a.foo'. its hard to figure out what 'foo' now refers to from inspecting the code. its better to be explicit: from a import foo from b import bar, baz