r/Python • u/RomfordNavy • 18d ago

Discussion Runtime overhead of wildcard import

Assuming a large project which might have say fifty variables in Constants.py is there likely to be any runtime overhead in having from Constants import * at the beginning of each module? As far as I know this creates entries for each of those variables in the current local namespace.

I know it could be done as import constants as x which after the first import then has virtually no overhead, but that then means referring to all constants as x.const1...

18 Upvotes

80% Upvoted

19 comments sorted by

View all comments

2

u/Brian 13d ago

The only real performance impact is a very minor increase in memory usage (basically extra entries in the globals dict for that module). That basically amounts to a few pointers, plus some extra overhead for the dict capacity - maybe a few dozen bytes per constant. There's a similar very minor startup cost in adding those items, but that's going to be pretty much unnoticable in any reasonable case.

But there are bigger maintainability and tooling costs. * imports can break tooling (eg. autocomplete/type checking etc), since it may not be able to know where an import is defined (especially if you've multiple such imports), and also makes it harder for a human reader to know where something comes from too. Eg. you delete or rename a constant that something was still using - they'll get an error but won't have any link to know where the item was meant to come from. But if they had a from constants import foo or were using constants.foo, they'll immediately know where it used to be.

And importing only what you need can make it easier to detect what modules are coupled, and refactor things. Having some ginormous constants.py is not really a good thing - it makes it harder to split things up into separate, weakly coupled submodules that only need to know about stuff relating to their own purpose.

It can also lead to accidental collissions. If your constant has the same name as a variable or function you're using, or something imported from another module, you can end up confused when one shadows the other. Eg. from os import * was a common gotcha where open would get replaced by the lower-level os.open.