On Wed, Dec 3, 2014 at 5:28 AM, Gregory Ewing greg.ew...@canterbury.ac.nz
wrote:
Kasper Peeters wrote:
That may have been the design plan, but in Python 2.7.6, I definitely
am able to inject locals via PyEval_GetLocals() and have them be visible
both from the C and Python side;
What seems
I'm not sure how you think you're adding a local from C
code. If you're using PyEval_GetLocals(), that only gives
you a dict containing a *copy* of the locals; modifying
that dict doesn't change the locals in the function's frame.
That may have been the design plan, but in Python 2.7.6, I
Kasper Peeters wrote:
That may have been the design plan, but in Python 2.7.6, I definitely
am able to inject locals via PyEval_GetLocals() and have them be visible
both from the C and Python side;
What seems to be happening is that the dict created by
PyEval_GetLocals() is kept around, so you
def fun():
cfun_that_creates_q_in_local_scope()
def fun2():
cfun_that_wants_to_see_if_q_is_available()
So the Python side actually doesn't see 'q' directly at all.
I think you will need to elaborate.
Ok, here goes (and thanks for listening).
The
On 12/2/14 4:35 AM, Kasper Peeters wrote:
def fun():
cfun_that_creates_q_in_local_scope()
def fun2():
cfun_that_wants_to_see_if_q_is_available()
So the Python side actually doesn't see 'q' directly at all.
I think you will need to elaborate.
Ok, here goes
Kasper Peeters wrote:
I could in principle decide to make these settings a proper
Python object, and ask the user to create one and pass it along at
every C-function call.
I would make the C functions methods of the object holding
the settings. Your nested function example would then look
Ned Batchelder wrote:
I would use thread locals for this:
https://docs.python.org/2/library/threading.html#threading.local
You could get dynamic scoping that way, but the OP
seems to want lexical scoping.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Kasper Peeters wrote:
I have something like
def fun():
cfun_that_creates_q_in_local_scope()
def fun2():
cfun_that_wants_to_see_if_q_is_available()
So the Python side actually doesn't see 'q' directly at all.
I am willing to elaborate on this if you want
I think
I have a question about PyEval_GetLocals(). The normal behaviour of
PyEval_GetLocals(), and in fact of the locals() function in Python
itself, is to return a list which includes only those variables which
are actually referenced in the local scope. Example:
def fun():
q=3
def fun2():
On Wed, Nov 26, 2014 at 9:22 PM, Kasper Peeters kas...@phi-sci.com wrote:
That is, I want
to do:
def fun():
q=3
def fun2():
cfun()
fun2()
fun()
and access 'q' inside the C-function cfun(). If I simply let it call
PyEval_GetLocals, then the result will again
def fun():
q=3
def fun2():
cfun()
fun2()
fun()
and access 'q' inside the C-function cfun(). If I simply let it call
PyEval_GetLocals, then the result will again not contain q. Is
there any way in which I can convince python to pull 'q' into the
On Wed, Nov 26, 2014 at 9:46 PM, Kasper Peeters kas...@phi-sci.com wrote:
I agree that in this example that would be the natural thing to do.
My case is more tricky though: I have something like
def fun():
cfun_that_creates_q_in_local_scope()
def fun2():
To be honest, that's just made it even more weird :) You're creating
something in a local namespace that the Python compiler isn't aware
of.
Yes, I agree that retrieving the locals with PyEval_GetLocals and then
sticking something in there on the C side is weird. I wouldn't say that
the Python
13 matches
Mail list logo
