Will the folks using forks be happy to switch to the stdlib version? 
>For example I can imagine that if black wants to process 3.7 input
>code while running on 3.6, it might prefer a parser on PyPI even if
>he stdlib version were public, since the PyPI version can be updated
>independently of the host Python.
The tool can parse arbitrary grammars, the one that is packed into is just one of them.

I think it would be useful, among other things because the standard library
lacks currently a proper CST solution. The ast module is heavily leveraged for
things like formatters, static code analyzers...etc but CST can be very useful as
Łukasz describes here:


I think is missing an important gap in the stdlib and the closest thing we have
(the current parser module) is not useful for any of that. Also, the core to generating
the hypothetical new package (with some new API over it may be) is already undocumented
as an implementation detail of lib2to3 (and some people are already using it directly).



On Thu, 16 May 2019 at 23:41, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, May 16, 2019 at 2:13 PM Pablo Galindo Salgado
<pablogsal@gmail.com> wrote:
> I propose to remove finally the parser module as it has been "deprecated" for a long time, is almost clear that nobody uses it and has very limited usability and replace it (maybe with a different name)
> with pgen2 (maybe with a more generic interface that is detached to lib2to3 particularities). This will not only help a lot current libraries that are using forks or similar solutions but also will help to keep
> synchronized the shipped grammar (that is able to parse Python2 and Python3 code) with the current Python one (as now will be more justified to keep them in sync).

Will the folks using forks be happy to switch to the stdlib version?
For example I can imagine that if black wants to process 3.7 input
code while running on 3.6, it might prefer a parser on PyPI even if
the stdlib version were public, since the PyPI version can be updated
independently of the host Python.

-n

--
Nathaniel J. Smith -- https://vorpus.org