[issue31753] Unnecessary closure in ast.literal_eval

2021-05-12 Thread Terry J. Reedy
Change by Terry J. Reedy : -- resolution: -> rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31753] Unnecessary closure in ast.literal_eval

2021-05-12 Thread Thierry Excoffier
Thierry Excoffier added the comment: I assumed that the standard python library does not create circular references, so the GC can be disabled safely in real time application. Each time 'literal_eval' is called, it creates a circular reference and so a memory leak. The source of this leak

[issue31753] Unnecessary closure in ast.literal_eval

2019-03-20 Thread Aaron Hall
Aaron Hall added the comment: No need to keep this open, I agree with the core developers this shouldn't be changed. -- status: open -> closed ___ Python tracker ___

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-17 Thread Raymond Hettinger
Raymond Hettinger added the comment: I question those timings. Here's the results from a script I've been using for many years: $ python3.6 variable_access.py 0.065 read_local 0.068 read_nonlocal 0.179 read_global 0.236 read_builtin 0.267 read_classvar

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-17 Thread Aaron Hall
Aaron Hall added the comment: New information: I think I have pinpointed at least a contributor to the difference - closure lookups seem to be currently slightly slower (by a few percent) than global lookups (see https://stackoverflow.com/a/46798876/541136). And as we

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-17 Thread Aaron Hall
Aaron Hall added the comment: Static analysis: My mental model currently says the rebuilt function every outer call is an expense with no offsetting benefit. It seems that a function shouldn't build a closure on every call if the closure doesn't close over anything

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-13 Thread Terry J. Reedy
Terry J. Reedy added the comment: On win10, installed 3.7.0a1, speedup is 7-8% (It is 'only' 5% on repository debug build that takes 5-6 times longer.) -- nosy: +terry.reedy ___ Python tracker

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-12 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: I prefer the existing code too. But I'm surprised that this change has a measurable effects at all. I thought that creating a closure is cheaper. Of course it is much faster than creating a class. Maybe it is worth to spend

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-12 Thread Raymond Hettinger
Raymond Hettinger added the comment: I prefer the existing code and think this shouldn't be changed. -- nosy: +rhettinger ___ Python tracker

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-11 Thread Aaron Hall
Aaron Hall added the comment: So... moving the closure (which may be called recursively) to the global scope actually does improve performance (for small cases, about 10% - larger cases amortize the cost of the closure being built, but in a 100 item dictionary, still

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-10 Thread Aaron Hall
Aaron Hall added the comment: Rejecting and withdrawing with apologies. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-10 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Test more complex examples including list and dict displays, binary operators. -- nosy: +serhiy.storchaka ___ Python tracker

[issue31753] Unnecessary closure in ast.literal_eval

2017-10-10 Thread Aaron Hall
New submission from Aaron Hall : Removing the closure seems to make the function about 10% faster. Original source code at: https://github.com/python/cpython/blob/3.6/Lib/ast.py#L40 Empirical evidence: astle.py import timeit from ast import literal_eval as