[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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

[Python-Dev] [RELEASE] Python 3.9.0a1 available for testing

Go get it here: https://www.python.org/downloads/release/python-390a1/ This is an early developer preview of Python 3.9 Python 3.9 is still in development. This releasee, 3.9.0a1 is the first of six planned alpha releases. Alpha releases

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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?

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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´): > >

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

> (*) 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

[Python-Dev] Re: Hold multiple tracebacks per-object in tracemalloc

Hi, Le mar. 19 nov. 2019 à 18:33, Sümer Cip a écrit : > First of all, I would like to thank for such a useful tool for debugging > memory issues. I am pretty proud as a Python lover that we have such a tool: > tracemalloc:) As the module author: you're welcome ;-) > AFAIU, tracemalloc holds

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

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

[Python-Dev] Hold multiple tracebacks per-object in tracemalloc

Hi everyone, First of all, I would like to thank for such a useful tool for debugging memory issues. I am pretty proud as a Python lover that we have such a tool: tracemalloc:) I would like to ask if something is feasible/practical regarding tracemalloc: AFAIU, tracemalloc holds a single