This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients pablogsal, vstinner
Date 2019-12-16.18:12:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
In-reply-to
Content
Pablo Galingo Salgado recently moved Tools/parser/unparse.py to a ast.unparse() function.

Pablo made a change using functools. The additional "import functools" made "import ast" slower and so Pablo reverted his change:

* https://github.com/python/cpython/pull/17376
* https://bugs.python.org/issue38870

The question of using contextlib comes back in another ast.unparse change to get @contextlib.contextmanager:

* https://github.com/python/cpython/pull/17377#discussion_r350239415

On the same PR, I also proposed to use import enum:

* https://github.com/python/cpython/pull/17377#discussion_r357921289

There are different options to not impact "import ast" performance:

* Move ast.unparse() code into a new module
* Write to code so imports can be done lazily

"from ast import unparse" or "ast.unparse()" can be kept using a private _ast_unparse module and add a __getattr__() function to Lib/ast.py to lazily bind _ast_unparse.unparse() to ast.unparse().

Other options:

* Avoid cool enum and functools modules, and use simpler Python code (that makes me sad, but it's ok)
* Accept to make "import ast" slower
* Remove ast.unparse(): I don't think that anyone wants this, ast.unparse() was approved on python-dev.
History
Date User Action Args
2019-12-16 18:12:54vstinnersetrecipients: + vstinner, pablogsal
2019-12-16 18:12:54vstinnersetmessageid: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
2019-12-16 18:12:54vstinnerlinkissue39069 messages
2019-12-16 18:12:53vstinnercreate