There have been a few warnings already when testing locally. Let's see what CI says.

I did some manual testing of this a while back -- I believe mypy also does not support this in a stub file, even though the CI is green. IIRC, it doesn't recognise any objects from typing as being actually imported in a from typing import * statements if we define __all__ like this.

I added a test case that passes, but that may be because of the special casing of typing. I'm trying another module.

I added a test case that passes, but that may be because of the special casing of typing. I'm trying another module.

Right, I misremembered. I think I was trying to do something more ambitious in asyncio — I was trying to do something like this:

if sys.version_info >= (3, 7):
    __all__ += runners.__all__

That's not supported by mypy IIRC.

If this works, it would allow us to reasonably define os.__all__ in the stubs. It would expose os._exit, which type checkers currently treat as private even though it's documented.

Looks like it also breaks pytype, though.

I'm curious if pytype views __all__.append/extend more favourably, since that is less of a "definition" than += and we might hit a different code path

PyCQA/flake8-pyi#219 for the flake8-pyi error

@erictraut It seems that pyright doesn't accept the advanced __all__ constructs in stubs yet. Is that something you would consider changing?

@srittau, the __all__ constructs work fine in stubs, but the reportInvalidStubStatement is being triggered here. Yeah, I can change the logic in reportInvalidStubStatement to accept the statement forms that manipulate __all__.

I've filed this issue. Should be easy to fix. I'll probably publish the next version of pyright on Fri or Sat at the latest. If you can wait until then, great. If you want to move forward with this PR in the meantime, you could temporarily disable the reportInvalidStubStatement rule in pyrightconfig.json.

I've filed microsoft/pyright#3485. Should be easy to fix. I'll probably publish the next version of pyright on Fri or Sat at the latest. If you can wait until then, great. If you want to move forward with this PR in the meantime, you could temporarily disable the reportInvalidStubStatement rule in pyrightconfig.json.

Thanks! We are not in a rush with this PR and there are a few more problems that we need to take a look at.

Also Cc @rchen152: Is all += ... something that pytype could support reasonably soon in stubs?

Also Cc @rchen152: Is all += ... something that pytype could support reasonably soon in stubs?

I'll open a pytype issue for it. (I'm about to head out of town for two weeks, so I'll look into this when I get back if none of the other devs have resolved it in the meantime.)

I've address the issue in pyright. The fix will be included in version 1.1.248, which I will publish within the next 48 hours.

I've published pyright 1.1.248, which includes this fix.

I've published pyright 1.1.248, which includes this fix.

Pyright tests are now passing — thanks, as always, for the extremely quick fix!

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

Thanks everyone for the support!