# BUG: from mymodule import \* overrides dict builtin

**URL:** <https://forum.inductiveautomation.com/t/bug-from-mymodule-import-overrides-dict-builtin/107371>\
**Category:** Ignition\
**Tags:** scripting, ignition81\
**Created:** [June 13, 2025, 3:22pm UTC](https://forum.inductiveautomation.com/t/bug-from-mymodule-import-overrides-dict-builtin/107371 "2025-06-13T15:22:16Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\
**Post date:** [June 13, 2025, 3:22pm UTC](https://forum.inductiveautomation.com/t/bug-from-mymodule-import-overrides-dict-builtin/107371/1 "2025-06-13T15:22:16Z")

</div>

Just upgraded from **v7.9.21** to **v8.1.48** and am working through migration stuff.

If I make a module, such as `shared.foo` in the `global` project and then try to run `from shared.foo import *` from another module, `shared.bar`, the following gets imported even though the `shared.foo` is empty:

`{'getDict', 'setName', 'dict', 'getCode', 'toString', 'path', 'getPath', 'reloadModule', 'code', 'getName', 'setCode', 'loadModule', 'name'}`

It appears IA added these methods/attributes into modules at some point in these newer versions, which breaks existing code making use of `import *` with modules without ` __all__ ` defined.

The most immediate issue with this design is that `dict` is a builtin and is being overridden with a dictionary instance, which is breaking attempts to:

- make a dictionary using `dict()` call
- isinstance(object, dict) calls because dict is now a dictionary instance

Is there a way to change the way `import *` works so it does not include a bunch of stuff not actually visible in the module being imported from?

Or any way to remove these methods/attributes from module namespaces, at the very least the attributes which seem likely to conflict with things in the module i am importing into?

If not, I can see the following workarounds for my codebase:

- use ` __all__ ` in every module I am using `import *` with. ` __all__ ` is already used for some of them and avoids importing this stuff.
- rewrite all `import *` statements in codebase to specifically identify objects needed. This is probably impractical due to design decisions made previously and the breadth of the codebase.

These solutions are not ideal as it will eat up some time to go through the existing code and we always run the risk of accidentally missing something somewhere or making the mistake again in the future.

Any suggestions would be appreciated.

UPDATE: tested in Script Console, `from shared.foo import *` and `dict` is not overridden. Issue somehow seems specific to when one module imports another module.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 13, 2025, 3:32pm UTC](https://forum.inductiveautomation.com/t/bug-from-mymodule-import-overrides-dict-builtin/107371/2 "2025-06-13T15:32:00Z")

</div>

> [@cmaynes](#):
>
> Any suggestions would be appreciated.

Remove **all** of your imports pointing at project library scripts. Use fully-qualified names for objects/classes in project library scripts. It has never been safe to use import targeting project library scripts. That it is now less safe in v8.x is unfortunate, but not surprising.

---

<div class="post-metadata">

**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\
**Post date:** [June 13, 2025, 3:50pm UTC](https://forum.inductiveautomation.com/t/bug-from-mymodule-import-overrides-dict-builtin/107371/3 "2025-06-13T15:50:04Z")

</div>

🙂 Thanks, @pturmel. You would know best.

Sounds like I am boned. I am way too far down my current road with too much to rewrite as you say in any sane timeframe. I guess I can figure something out using ` __all__ ` and an `ast` script to update the existing code and then try doing what you say on all future projects.