missing type stubs for libcst.native

[jakkdl]

E.g. libcst.parse_module is wonderfully typed, but libcst.native.parse_module has no stubs.
I don't think it should be too bad to write .pyi files for the functions in libcst.native despite them being hooked in with PyO3?

[zsol]

You're not supposed to call libcst.native.parse_module, that's considered a private API (maybe this should be documented better). libcst.parse_module is the API users are expected to call, and that will delegate to libcst.native.parse_module if LIBCST_PARSER_TYPE=native env var is set.

[jakkdl]

The normal parser crashes on our test files in flake8-trio, and presumably any time a user wants to lint code containing new grammar, so I see no reason not to always call the native parser? I suppose I could set the env var in the program before calling parse_module, though that feels kinda cumbersome.

[zsol]

I suppose I could set the env var in the program before calling parse_module, though that feels kinda cumbersome.

Agreed, libcst should call the native parser by default. I was hesitant to make that change, because there are some features of parse_module that the native parser doesn't support (most importantly limiting the [python_version](https://github.com/Instagram/LibCST/blob/main/libcst/_parser/types/config.py#L80), but I don't think anyone will have the time to work on these features anytime soon. At some point the burden of setting that env var will outweigh the benefits of these missing features...

[jakkdl]

ah that's a shame, but I'll just set os.environ for now then.

Better documentation does sound good, and/or adding some leading underscores / not exporting parser.native.

[Zac-HD]

Yeah, I went with https://github.com/Zac-HD/shed/blob/f3653b21987172d4c7b3b369d8067116f5edc919/src/shed/_codemods.py#L39-L48 - it's a bit awkward but not too bad and libcst is still so much nicer overall🙂

[zsol]

I'm going to close this out now that #929 has been merged.