Hi, Le mar. 19 nov. 2019 à 01:42, Pablo Galindo Salgado <pablog...@gmail.com> 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 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. (*) unparse adds many useless parenthesis. The algorithm seems naive. For example, it adds "()" to "class _AddedDllDirectory():". It also adds parenthesis around yield, like "(yield (top, dirs, nondirs))", whereas the AST node was at "top level": it isn't a sub-expression. Maybe this algortihm should be made smarter. (*) the main() function is only used for testing. I would prefer to move this code to Lib/test/test_tools/test_unparse.py and simply remove it. For example, to avoid "import os" in unparse. (*) newlines in docstring are rendered as two characters: "\\" + "n" (escaped newline: \n), rather than a newline character. I would expect a newline, it's more common that \n... But it may "break" inline doctests rendering... Maybe it should be an option (render newlines as newline character or escape them?), or maybe even let the user choose how to render them using a callback (that's related to the "pluggable formatter" question). (*) Do you plan to provide any warranty about the output stability? Like Black formatter which tries to avoid changing output between minor versions. Or should we expect to get a different output per Python version? If we provide a warranty, new tests should be written. Currently, test_unparse only compares AST, not the text output. (*) Indentation is hardcoded to 4 spaces. What if I want 2 spaces or something different? Should it become an option? (*) Float infinity is replaces with 1e309. Again, maybe someone wants to render this differently? It sounds like an arbitrary choice (which "works" as expected). (*) Do we talk about 'string' vs "string" quotes? :-) Maybe it would help to have a written down PEP to answer to these questions and maybe specify the module API. > We could add the public interface to the ast.py module or a new one if people > feel strongly about it. I would prefer to keep a separated module, like "import ast.unparse" or "import unparse". Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EU7FGOUGEUYBOA74U4OHZH2236VR3NTZ/ Code of Conduct: http://python.org/psf/codeofconduct/
