mypy: Module has no attribute "connect" [attr-defined]
See original GitHub issueAs of mypy 0.730 using no_implicit_reexport = True errors are reported when importing names from the top-level module. I’m guessing this is due to mypy not being able infer the dynamic contents of __all__, and instead having relied on inferring the imports previous to 0.730.
Would you be open to a pull request that hard-codes the contents of __all__ instead of building it dynamically from the __all__s of submodules?
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
mypy gives an error while importing submodule : Module has ...
It appears that your problem is similar to this issue raised in mypy 's github repo: Module X has no attribute Y, since...
Read more >Error codes - mypy 0.991 documentation
mypy prog.py prog.py:1: error: "str" has no attribute "trim" [attr-defined]. It's also possible to require error codes for type: ignore comments.
Read more >Mypy Documentation - Read the Docs
Mypy complains if it can't find a stub (or a real module) for a library module that ... error: "str" has no attribute...
Read more >python/typing - Gitter
Here is an output for mypy: src/check.py:15: error: "object" has no attribute "append" [attr-defined] src/check.py:17: note: Revealed type is 'T`1' ...
Read more >mypy — Debian unstable
Mypy has a powerful and easy-to-use type system with modern features ... import NonExisting # Error: Module has no attribute 'NonExisting'.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yes, that would be the most straight forward approach, if it weren’t for backwards-compatibility.
I always documented the import paths as
websockets.connectandwebsockets.serverather thanwebsockets.client.connectandwebsockets.server.serve. I did to keep things simple: just import anything you need fromwebsockets.This strategy has unfortunate consequences but I feel it’s best to live with the consequences.
I’d be open to that, with a test that checks that
assertEquals(set(websockets.__all__), set(<current definition>)). There’s no obvious place to put that test; try something; it won’t be hard to change later anyway.Ideally, I’d like to perform imports on demand, so programs that only use the client side don’t load the server side needlessly and vice-versa. This will likely open a whole can of worns so it shouldn’t prevent a quick improvement here.