Nick Coghlan ncogh...@gmail.com added the comment:
Attached patch implements both new functions, but I'm going to drop
getgeneratorlocals for now and move that idea to a new issue.
--
Added file: http://bugs.python.org/file26103/issue13062-combined.diff
Nick Coghlan ncogh...@gmail.com added the comment:
I created #15153 to cover getgeneratorlocals. Attached patch is just for record
keeping purposes - I'll be committing this change shortly.
--
Added file: http://bugs.python.org/file26104/issue13062-getclosurevars.diff
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 487fe648de56 by Nick Coghlan in branch 'default':
Close #13062: Add inspect.getclosurevars to simplify testing stateful closures
http://hg.python.org/cpython/rev/487fe648de56
--
nosy: +python-dev
resolution:
Nick Coghlan ncogh...@gmail.com added the comment:
Meador: I probably won't get to this until the weekend, so go ahead and update
the patch if you have time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I didn't get around to updating my patch with Nick's comments yet.
Nick, the v3 patch I have attached still applies. I am happy to update it per
your comments (promptly this time) or you can take it over. Whichever.
--
Meador Inge mead...@gmail.com added the comment:
Nick, the revised definition of 'getclosurevars' seems reasonable to me.
I will cut a new patch this week.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
Nick Coghlan ncogh...@gmail.com added the comment:
No, the naming problem had occurred to me as well. Given the 'vars' builtin,
perhaps 'getclosurevars' would do as the name?
--
___
Python tracker rep...@bugs.python.org
Meador Inge mead...@gmail.com added the comment:
perhaps 'getclosurevars' would do as the name?
I like vars. Updated patch attached.
--
Added file: http://bugs.python.org/file23368/issue13062-3.patch
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
In reviewing Meador's patch (which otherwise looks pretty good), I had a
thought about the functionality and signature of getclosurevars().
Currently, it equates closure to nonlocal scope, which isn't really true -
the function's closure is
Changes by Ron Adam ron3...@gmail.com:
--
nosy: +ron_adam
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list mailing
Meador Inge mead...@gmail.com added the comment:
Here is an updated patch with error handling. One other thought is that
'getclosure' should be called something like 'getclosureenv' since
technically a closure is a function plus its environment and our
implementation only returns the
Meador Inge mead...@gmail.com added the comment:
Here is a first cut at a patch. There is one slight deviation from the
original spec:
some nice error checking for when the generator's frame is already gone (or
the supplied object isn't a generator iterator).
The attached patch returns
Nick Coghlan ncogh...@gmail.com added the comment:
Because a generator can legitimately have no locals:
def gen():
... yield 1
...
g = gen()
g.gi_frame.f_locals
{}
Errors should be reported as exceptions - AttributeError or TypeError if
there's no gi_frame and then ValueError or
Nick Coghlan ncogh...@gmail.com added the comment:
The function case is simpler - AttributeError or TypeError if there's no
__closure__ attribute, empty mapping if there's no closure.
I've also changed my mind on the no frame generator case - since that mapping
will evolve over time as the
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +durban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
New submission from Nick Coghlan ncogh...@gmail.com:
Based on the python-ideas thread about closures, I realised there are two
features the inspect module could offer to greatly simplify some aspects of
testing closure and generator behaviour:
inspect.getclosure(func)
Returns a
Changes by Meador Inge mead...@gmail.com:
--
components: +Library (Lib)
stage: - needs patch
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
Changes by Yury Selivanov yseliva...@gmail.com:
--
nosy: +Yury.Selivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I'll take a shot and writing a patch for this one. Nick, are the
elements in 'co_freevars' and '__closures__' always expected to match
up? In other words, is the 'closure' function below always expected to
work (simplified; no error checking):
Eric Snow ericsnowcurren...@gmail.com added the comment:
See:
http://hg.python.org/cpython/file/default/Include/funcobject.h#l34
http://hg.python.org/cpython/file/default/Objects/funcobject.c#l454
454 /* func_new() maintains the following invariants for closures. The
455closure must
Nick Coghlan ncogh...@gmail.com added the comment:
Yep, that looks right to me. The eval loop then references those cells from the
frame object during execution.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
Nick Coghlan ncogh...@gmail.com added the comment:
Huh, I didn't actually realise getclosure() could be written as a one liner
until seeing Meador's version above:
{var : cell.cell_contents for var, cell in zip(func.__code__.co_freevars,
func.__closure__)}
--
25 matches
Mail list logo
