explicitly list exported package symbols

[alinsavix]

Currently, gspread uses implied exports for all of its externally-accessible symbols. This works fine, but it makes some type checkers complain. In particular, pylance (the default type checker for python in VSCode) flags an issue. mypy will as well, if run with the --no-implicit-reexport.

The following script can be used to see this in action:

#!/usr/bin/env python3
import gspread
gspread.service_account(filename="example.json")

pylance will return this warning: "service_account" is not exported from module "gspread"

mypy --no-implicit-reexport will return: error: Module "gspread" does not explicitly export attribute "service_account" [attr-defined]

Some brief notes about implicit and explicit exports are available in the mypy documentation, see e.g. https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-no-implicit-reexport . The choices for fixing this problem are to either use the "from-as" import format for all the symbols in the top level __init__.py file, or to explicitly list all of the intended exports explicitly in an __all__ list in that file. I've chosen the latter of those two choices, as it is generally good form to do so.

There should be no actual behavior change with this patch beyond making fewer red lines in peoples' editors.

[alinsavix]

I see the lint failures on this, but I would actually disagree with the linter in this case -- it's complaining that there are gaps (extra newlines) in the list of exportable symbols, but those gaps are there to work as separators between each individual source of symbols. If the gaps are removed, the comments showing where things are from end up looking more like commented-out list items than actual useful comments.

I'm happy to adjust to make the linter happy, though, if that's desired, just have to let me know.

[alifeee]

hi ! sorry for the delay

this is a great addition :)

it will be very helpful for automatic code completers

I agree with you on the linter. If you feel you can change it so it doesn't complain, then great ;)

[alinsavix]

I can change it so it doesn't complain, but that would require removing the whitespace that makes it more readable, so might not be desirable. Which way would you prefer?

[alifeee]

I have ignored __init__.py from the linting, as I don't think it's important that this file be formatted strictly. This is more for our code files.

With that, I am happy to merge this :)

I will let @lavigne958 merge this ;]

[vstollen]

Hey everyone, just wanted to check in and ask if there is any news on this. Just stumbled upon this because Pyright also raises this as an error in its default configuration.

[alifeee]

Hey everyone, just wanted to check in and ask if there is any news on this. Just stumbled upon this because Pyright also raises this as an error in its default configuration.

hi !

you should get this now in the latest release 6.2.0 :]