slackapi/python-slack-sdk

VSCode (with jedi) can't suggest imports beyond base level of package

Opened this issue · 5 comments

I'm trying to import classes defined in the SDK but for some reason it won't suggest imports beyond:

  • WebClient
  • WebhookClient

The imports I am looking for are SlackResponse, any of the Block classes (SectionBlock, ...) . If I manually import them they work fine and if I run pip list, slack-sdk shows up correctly.

Any ideas?

The Slack SDK version

slack-bolt==1.18.1
slack-sdk==3.26.1
slack-webhook==1.0.3

Python runtime version

Python 3.8.13

ProductName: macOS
ProductVersion: 13.1
BuildVersion: 22C65
Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000

Steps to reproduce:

image
image

Expected result:

I'd expect the SectionBlock suggestion to show up.

Actual result:

See previous screenshots

Requirements

For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi @xxkennyxu, thanks for writing in. This seems to be a limitation on the lang server integration with VS Code. If this project add all possible module names into __all__ variable in https://github.com/slackapi/python-slack-sdk/blob/main/slack_sdk/__init__.py , perhaps more names will show up. However, some of the class/type names can conflict, plus even if there is no name conflict, it brings more maintainance cost to this project. Thus, we hesitate to make such changes.

If you need a more intelligent code editor, one great option would be PyCharm IDE: https://www.jetbrains.com/pycharm/ I've been a PyCharm user for a long time, and it does not have the issue you mentioned here. PyCharm Professional requires a paid license, but when you don't use it for work, the community edition (free) is also available.

I hope this helps.

Hi Kaz!

As a heavy user of VS Code, I wanted to jump in and provide a bit of info.

First, let me just say I’m not a fan of the __all__ approach; it exists to define the symbols that should be imported when using a wildcard import.

The problem stems from the fact that Python doesn't have keywords like public, private or export to allow devs to be explicit about access control. One of the “solutions” to this is defined in PEP-484: redundant imports. This is how pyright and pylance (used by VS Code) determine if something is “public” and available for Intellisense. Redundant imports are also supported by mypy and ruff (flake8 uses __all__).

I recently saw redundant imports in dilib if you want to see an example.

All that being said, adding and maintaining all the appropriate redundant imports would still be significant!

Thanks for the knowledge @eddyg, I was not aware about the stub file "solution"

Have you seen this implemented alongside the __all__ approach, wondering if we could be added it in without impacting users

I can't think of any projects where I've seen both redundant imports and __all__. According to Kaz's comment above, he is hesitant to add more things to __all__ since it will bring "more maintainance cost to this project". (And as I mentioned, I see __all__ encouraging wildcard imports, which in my opinion should be avoided). But keeping redundant imports updated would also add extra maintenance costs to this project as well. My comment was to mostly intended to provide insight into how VS Code finds "public" Python code.

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.