PyLance import of inner packages works incorrectly

[wvolkov]

Environment data

• Language Server version: Pylance language server 2020.12.2
• OS and version: Windows_NT x64 10.0.19041
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.7.9
• WSL: Ubuntu 20.04
• VS Code: 1.52.1

Expected behaviour

1. pip install asyncpg
2. import asyncpg
3. pylance will show class PosrtgesError after hitting psycopg.Post at editor

Actual behaviour

3. pylance intellisence doesn't seem to find that class:
   

while it still can show that via inner class exceptions:

Code Snippet / Additional information

import asyncpg
asyncpg.PostgresError

If we look at inner structure at asyncpg module (available at github here)
there is a mention of that class via all reference but with tuple, not list:

# ... at 13 line
__all__ = ('PostgresError', 'FatalPostgresError', 'UnknownPostgresError',
           'InterfaceError', 'InterfaceWarning', 'PostgresLogMessage',
           'InternalClientError', 'OutdatedSchemaCacheError', 'ProtocolError',
           'UnsupportedClientFeatureError')
# ...

maybe that is the way of it is not working properly.

[jakebailey]

Curious, I think a tuple should work. If you go and edit the file to be a list, does it work?

@erictraut Do you know off the top of your head if we are strict about it only being a list?

[erictraut]

We support lists and tuples. You can find a list of all supported idioms here.

[jakebailey]

Thanks for the clarification. We'll have to look closer at this one, then.

[bschnurr]

if you look at asyncpg.__init__.py you'll see they are dynamically building __all__

__all__ = (
    ('connect', 'create_pool', 'Pool', 'Record', 'Connection')
    + exceptions.__all__  # NOQA
)

[jakebailey]

Hm, this should be one of the patterns we support.

[bschnurr]

ahh. PostgresError isn't in that list. oh correction its another indirection _base.__all__

in exceptions\__init__.py

__all__ = _base.__all__ + (

[jakebailey]

But, __all__ is for import *, so it's omission there may or may not imply it should be externally visible.

[erictraut]

No, this isn't a pattern we support. This example is using using a nested tuple expression within a tuple expression.

[erictraut]

Here's the specific set of patterns that we support: https://github.com/microsoft/pyright/blob/main/docs/typed-libraries.md#library-interface

So this would work:

__all__ = ['connect', 'create_pool', 'Pool', 'Record', 'Connection']
__all__.extend(exceptions.__all__)

[jakebailey]

Maybe I'm missing something but it's just parenthesis at the top level; it's functionally equivalent to ('foo', 'bar') + something.__all__.

[erictraut]

At the point where we handle __all__, we have no type information. We're looking for very specific parse tree patterns. It's very strict. It's not feasible for us to handle deviations. That's why we explicitly defined (and standardized) the list of patterns that we support.

[jakebailey]

Sure. I was just surprised that this was one we didn't handle.

[bschnurr]

This seems like a bug after I edit asyncpg/exceptions/__init__.py

doens't work

__all__ = _base.__all__

works

__all__ = []
__all__.extend(_base.__all__)

where _base.all is

__all__ = ['PostgresError', 'FatalPostgresError', 'UnknownPostgresError',
           'InterfaceError', 'InterfaceWarning', 'PostgresLogMessage',
           'InternalClientError', 'OutdatedSchemaCacheError', 'ProtocolError',
           'UnsupportedClientFeatureError']

[erictraut]

__all__ = _base.__all__ is not a pattern we support. The very specific list of supported patterns is here: https://github.com/microsoft/pyright/blob/main/docs/typed-libraries.md#library-interface. If you stick to the list of standardized supported patterns, it will work fine.

[bschnurr]

yup. thank you. i'm submitting a change to asyncpg