Opened https://bugs.python.org/issue38870 to track this.
On Tue, 19 Nov 2019 at 00:40, Pablo Galindo Salgado
wrote:
> Hi,
>
> What do people feel about exposing Tools/parser/unparse.py in the standard
> library? Here is my initial rationale:
>
> * The tool already needs to be maintained and
On Thu., 21 Nov. 2019, 3:30 am Brett Cannon, wrote:
> Victor Stinner wrote:
> > > It's mostly to minimize the number of imports on "import ast". unparse
> > requires extra imports like tokenize which has also tons of
> > dependencies.
>
> Why are you specifically worried about that? If you're
Victor Stinner wrote:
> Le mar. 19 nov. 2019 à 22:12, Pablo Galindo Salgado
> pablog...@gmail.com a écrit :
> > Float infinity
> > is replaced with 1e309. Again, maybe someone wants
> > to render this differently? It sounds like an arbitrary choice (which
> > "works" as expected).
> > That is not
Yes, there is a to_source function which allows AST to source conversation.
On Wed, Nov 20, 2019, 9:02 AM Guido van Rossum wrote:
> On Tue, Nov 19, 2019 at 10:24 PM Nathaniel Smith wrote:
>
>> On Mon, Nov 18, 2019 at 4:41 PM Pablo Galindo Salgado
>> wrote:
>> >
>> > Hi,
>> >
>> > What do
On Tue, Nov 19, 2019 at 10:24 PM Nathaniel Smith wrote:
> On Mon, Nov 18, 2019 at 4:41 PM Pablo Galindo Salgado
> wrote:
> >
> > Hi,
> >
> > What do people feel about exposing Tools/parser/unparse.py in the
> standard library? Here is my initial rationale:
> >
> > * The tool already needs to be
Just wanted to add my +1 to this idea. Moving it to ast module will add
little maintenance costs, but will make it easier to use.
--
Ivan
On Tue, 19 Nov 2019 at 00:46, Pablo Galindo Salgado
wrote:
> Hi,
>
> What do people feel about exposing Tools/parser/unparse.py in the standard
> library?
Le mar. 19 nov. 2019 à 22:12, Pablo Galindo Salgado
a écrit :
> > Float infinity is replaced with 1e309. Again, maybe someone wants
> to render this differently? It sounds like an arbitrary choice (which
> "works" as expected).
>
> That is not true. float('inf') is rendered as float('inf´):
>
>
This is a really great idea, after pretty ast.dump it will be great
addition for people who works with AST code transformations.
I think with the new end_lineno and end_col_offset information output can
be little bit close the original.
I want to volunteer the work if there is an open
On Mon, Nov 18, 2019 at 4:41 PM Pablo Galindo Salgado
wrote:
>
> Hi,
>
> What do people feel about exposing Tools/parser/unparse.py in the standard
> library? Here is my initial rationale:
>
> * The tool already needs to be maintained and updated as is tested as part of
> the test suite.
> * I
> (*) unparse loses all formatting and comments. The output is not
really "pretty". If you want to put unparse in the stdlib, maybe we
should design an API to be able to plug an external formatter to get
"PEP 8"-like coding style or Black coding style for example.
The ast does not have comment or
Hi,
Le mar. 19 nov. 2019 à 01:42, Pablo Galindo Salgado
a écrit :
> What do people feel about exposing Tools/parser/unparse.py in the standard
> library?
I like the idea. I compared Lib/os.py to the unparse output and now I
have many questions :-)
(*) unparse loses all formatting and
I don't think the PEG parser switch would change anything -- it produces
the same AST as the old parser and ast.parse().
It looks a reasonable thing to move into the stdlib (maybe as
ast.unparse()?), assuming it's complete. Tests and doc need to be written.
On Tue, Nov 19, 2019 at 1:08 AM
>From the first time I found it years ago, I've often wondered why it wasn't
exposed. I presumed due to certain API shifts I wasn't paying close
attention to, that maybe the ast module was buffering. But I've definitely
wanted to import it in the past.
If the API is as stable as you say, then I
13 matches
Mail list logo
