This repository has been archived by the owner on Apr 14, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 133
__all__ not being respected from an import *
#619
Milestone
Comments
An unfortunate side effect of handling this but only partially means that we may under complete in some situations (especially projects like Django which do lots of fun stuff). I've opened #620 to track improving the support. |
Merged
Repoening, the code which filters |
Merged
jakebailey
added a commit
that referenced
this issue
Apr 2, 2019
Fixes #620. Fixes #619. This adds support for concatenating lists using `+`, doing `+=` on `__all__`, and calling `append` and `extend` on `__all__`. If something goes wrong (an unsupported operation on `__all__` or some unsupported value), then the old behavior continues to be used. I don't track uses of `__all__` indirectly (i.e. passing `__all__` to something that modifies it), only direct actions. If `__all__` is in a more complicated lvar (like `__all__, foo = ...`), then it is ignored. This can be improved later on when we fix up our multiple assignment issues. This works well for Django models (see #620), but `numpy`'s import cycles prevent this from having an effect, so the old behavior will be used. ~Tests are WIP.~ I'll need to rebase/merge master when the refs per gets merged.
jakebailey
added a commit
to jakebailey/python-language-server
that referenced
this issue
Nov 1, 2019
Fixes microsoft#642. Reopens microsoft#619. Related microsoft#620. This unfilters exported variables except for things which are directly from typing or are imported modules, though even that may be too strong. The old LS didn't look at __all__ whatsoever, so maybe all of these should be allowed to come through; you tell me.
jakebailey
added a commit
to jakebailey/python-language-server
that referenced
this issue
Nov 1, 2019
Fixes microsoft#620. Fixes microsoft#619. This adds support for concatenating lists using `+`, doing `+=` on `__all__`, and calling `append` and `extend` on `__all__`. If something goes wrong (an unsupported operation on `__all__` or some unsupported value), then the old behavior continues to be used. I don't track uses of `__all__` indirectly (i.e. passing `__all__` to something that modifies it), only direct actions. If `__all__` is in a more complicated lvar (like `__all__, foo = ...`), then it is ignored. This can be improved later on when we fix up our multiple assignment issues. This works well for Django models (see microsoft#620), but `numpy`'s import cycles prevent this from having an effect, so the old behavior will be used. ~Tests are WIP.~ I'll need to rebase/merge master when the refs per gets merged.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
microsoft/vscode-python#494
The text was updated successfully, but these errors were encountered: