Provide an option to disable specific stubs in settings

[southwood]

This is a great project - very useful and much faster than other language servers.

However, I've noticed that the stubs aren't accurate for a lot of things. I would much rather navigate to the source definitions than see misleading stub interfaces. It's always edge-cases. Most of the stubs are correct. It took me longer than it should have to realize that my local language server had changed, and that pylance was ignoring the actual source files. Reminds me of the early days of tsds and DefinitelyTyped with reverse engineered type definitions.

Please add an exclusion list for stubs so that developers have a way to fall-back to source definitions other than switching the language server.

The best work-around I have found so far is to toggle "justMyCode": false, in the launch config and step-into code where the pylance stubs are misleading. Before VSCode started using pylance it was possible to navigate into the source definition of installed packages. This feature is much more useful than navigating into a stub definition even when the stubs are correct.

As a corollary, I suggest that the stubs not be used at all when viewing the source definition of an inferred function or class. Specifically with the f12 hot-key or right-click navigation of "Go To Definition".

[jakebailey]

Rather than jumping to a specific solution, I'd like to better understand the problems you're having first; we fully intend that things will work with the stubs present, and anything past that indicates that there are bugs to solve rather than just disabling stubs (which will only make things worse overall; inferencing is not going to go well, and comparing it to MPLS is a bit tough because it made a number of questionable inferencing decisions).

It seems like you're saying a set of stubs we bundle is incorrect in some way. Which stubs are incorrect? Are you trying to do type checking, or just use Pylance in its default state? We'd really be interested in making sure those stubs are fixed; we have our own stubs but source some from typeshed and other repos.

You mention navigation; we intend for navigation to work, just that stubs may appear as well. There are some oddities in how VS Code shows this, often putting preselecting the wrong file. There have been requests to allow disabling going to stubs at all (#65), and we are working on modifying our behavior to improve navigation and add customization. What behavior are you seeing? Do you have an example? Are you seeing both locations, or just one and it's the stub?

[southwood]

I see, thank you for the reply and clarifications.

I first noticed here with Django's AsyncClient:

• https://github.com/typeddjango/django-stubs/blob/2a732fd2573bcddabb7dc284467481b040d26944/django-stubs/test/__init__.pyi
• https://github.com/django/django/blob/master/django/test/__init__.py#L4

But, a number of things seemed broken. I'll take some notes next time I'm working with it.

I still think you should consider the feature to disable stubs for select packages. Thinking back to the early days of typescript and community sourced definitions in DefinitelyTyped, it was around 50% chance that tsds would pay-off vs causing more trouble than they averted for any given dependency.

My current workaround of disabling pylance isn't pretty but it's functionally more effective than disabling justMyCode and stepping into functions with a unit test each time I need to inspect something (which, is also often more effective than looking up the sources online or grep'ing for each one).

My ideal solution would allow me to leave pylance enabled in general for all dependencies (because it is fantastic, and much faster than jedi) except a specific deny-list if I suspect something isn't accurate. Once finished I'd remove everything from the deny-list and hope that the next time I sync'd things would have improved in the stubs. I'm guessing the number of packages covered by stubs will increase in the coming weeks / months, so this may become more important if there is any chance of inaccuracy.

[Xalaxis]

I have an issue that may be related to this? This is unfortunately mostly outside my understanding, so apologies if this is in the wrong place.

I'm using a beta version of SQLAlchemy, but as best I can tell PyLance is using some bundled stubs which mean that the new imports show as missing (as it only refers to the released version, even when a newer version is installed via pip). Would a setting like this allow me to tell PyLance to look at the installed packages rather than use the pre-shipped definitions?

[jakebailey]

The way things are ordered, our bundled stubs come last. I assume SQLAlchemy remains untyped, so we use the stubs we bundled. So yes, some configuration to do this would allow you to bypass these stubs.

For now, a workaround is to delete them from the Pylance distribution.

[Xalaxis]

Thanks! Deleting the types (from .vscode\extensions\ms-python.vscode-pylance-2021.2.3\dist\bundled\stubs\sqlalchemy) has fixed the ghosts telling me functions don't exist 😃 . I would support this feature to provide a way to ignore them in the configuration/GUI.

[strogonoff]

Any pre-bundled stubs should be opt-in, or the extension can simply ask the user to install stubs.

The golden rule is to be explicit, not implicit. I’m OK to be warned that typings are missing, and can install the requisite typings as I normally do. I’m not OK with IDE sneaking in code from third parties not vetted by core maintainers of the libraries I trust, and resulting typing mismatches.

[zzzeek]

SQLAlchemy maintainer here.

My 2c is that in SQLAlchemy 2.0 we hope (emphasis on hope...) to have the entire library typed within the source code. so to the degree that pylance will automatically use the .py file that has typing information vs. what it has in a stub, we're good, but I dont know the mechanics of that. However, if pylance still keeps consulting the stubs and confusing things, then we want to give our users instructions on how to use SQLAlchemy 2.0 and make sure no obsolete stubs are being pulled in from their IDE.

[erictraut]

@zzzeek, thanks for posting. It's great to hear that SQLAlchemy 2.0 might have full and complete inlined type information! I'm very encouraged and excited to hear that. Fingers crossed that you can make that happen. Let us know if there's anything we (the pylance and pyright maintainers) can do to help. (One thing that you might find useful is the "--verifytypes" option provided by the command-line version of pyright. It allows you to verify whether any public symbols in a py.typed library are missing type information.)

We release pylance every week (except for the next few weeks when we're on a hiatus for the holidays). We can therefore respond quickly once you have the SQLAlchemy 2.0 plans finalized. It's in everyone's best interest that pylance and SQLAlchemy work great together. Let's collaborate to figure out the best answer. Do you have a rough timeline for SQLAlchemy 2.0?