Skip to content
This repository has been archived by the owner on Apr 14, 2022. It is now read-only.

Handle complex __all__ assignments #620

Closed
jakebailey opened this issue Feb 15, 2019 · 1 comment · Fixed by #863
Closed

Handle complex __all__ assignments #620

jakebailey opened this issue Feb 15, 2019 · 1 comment · Fixed by #863
Assignees
@jakebailey
Milestone
March 2019.2

Comments

@jakebailey
Copy link
Member

We have basic __all__ handling, but won't be able to handle more complicated expressions. This will likely be required for #129.

Example:

https://github.com/django/django/blob/741ce81a426e4d0cd7581d98d3b8e3290f513f09/django/db/models/__init__.py#L35-L48

__all__ = aggregates_all + constraints_all + fields_all + indexes_all
__all__ += [
    'ObjectDoesNotExist', 'signals',
    'CASCADE', 'DO_NOTHING', 'PROTECT', 'SET', 'SET_DEFAULT', 'SET_NULL',
    'ProtectedError',
    'Case', 'Exists', 'Expression', 'ExpressionList', 'ExpressionWrapper', 'F',
    'Func', 'OuterRef', 'RowRange', 'Subquery', 'Value', 'ValueRange', 'When',
    'Window', 'WindowFrame',
    'FileField', 'ImageField', 'OrderWrt', 'Lookup', 'Transform', 'Manager',
    'Prefetch', 'Q', 'QuerySet', 'prefetch_related_objects', 'DEFERRED', 'Model',
    'FilteredRelation',
    'ForeignKey', 'ForeignObject', 'OneToOneField', 'ManyToManyField',
    'ManyToOneRel', 'ManyToManyRel', 'OneToOneRel',
]
@jakebailey jakebailey mentioned this issue Feb 15, 2019
Closed
@jakebailey jakebailey mentioned this issue Mar 6, 2019
Merged
jakebailey added a commit that referenced this issue Mar 6, 2019
@jakebailey
unfilter __all__ (#708)
1072de6 
Fixes #642.
Reopens #619.
Related #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
Copy link
Member Author

More examples:

@qubitron qubitron added this to the March 2019.2 milestone Mar 20, 2019
@jakebailey jakebailey self-assigned this Mar 20, 2019
This was referenced Mar 23, 2019
Merged
Closed
@jakebailey jakebailey mentioned this issue Apr 1, 2019
Merged
jakebailey added a commit that referenced this issue Apr 2, 2019
@jakebailey
__all__ evaluation (#863)
7bcb4b6 
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
@jakebailey
unfilter __all__ (microsoft#708)
6c2246a 
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
@jakebailey
__all__ evaluation (microsoft#863)
237a18c 
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.
Assignees

@jakebailey jakebailey

Labels
None yet
Projects
None yet
Milestone
March 2019.2
Development

Successfully merging a pull request may close this issue.

__all__ evaluation jakebailey/python-language-server
2 participants
@jakebailey @qubitron