Use `lazy_loader` for imports or implement stubs/hints in `lazy_import`

[wolph]

Most IDE's currently don't properly understand the example code due to the current implementation of the lazy_import function. Luckily, there's a simple solution for this besides changing your imports from import websockets to import websockets.client :)

There is a great little project called lazy_loader that effectively does the same as what lazy_import does now but it also properly supports type hints and stubs: https://github.com/scientific-python/lazy_loader#type-checkers

I believe a switch to lazy_loader, or an update for lazy_import if you want to avoid a dependency, could improve the usability of the library quite a bit.

[128f]

After reading this I was curious how this project gets built, and eventually went looking for signs of a dependency management tool, but I couldn't find one.

Then I found out It doesn't have any dependencies., which is rather incredible.

Given that, I would guess the maintainer of this project would be reluctant to add an outside project as a dependency.

[aaugustin]

I can confirm that I'm reluctant to add dependencies. Indeed, dependencies increase the cost of maintenance — simply because they increase the number of things that can change outside of my control — while I cannot dedicate much time to maintaining websockets.

I looked at lazy_loader when this issue was filed. It appears to require duplicating type information in .pyi files, which I don't want to do because it's yet another thing to maintain.

I think I'm just going to adopt explicit import paths everywhere eventually. Convenience imports were cool when the library was younger. We've outgrown them 🤷

[aaugustin]

PS: why would websockets need any dependencies? ;-)

[128f]

PS: why would websockets need any dependencies? ;-)

I know you're half kidding but it's quite shocking to me to see a library like this not have any at all.

Eg rust websocket has dependencies, and I would usually expect to see dev dependencies.

I was rather confused for a while, insisting to myself that I must be mistaken and just not seeing the dependency management artifacts.

Anyways, kudos to you for avoiding it altogether

[wolph]

I totally get that :) Many of my libraries have no dependencies or only dependencies I maintain myself. Less stuff that can break that way ;)

As a 3rd option, I believe that a stub file could fix it as well without requiring any other changes. The only issue with stub files is that they could become out of date. But this library is rather stable and you could easily have pyright automatically test for that.

[aaugustin]

439dafa6 should fix it. Duplicating 50 lines in a file is still easier to maintain than taking a dependency.