Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81799 > unrolled thread

Re: PyEval_GetLocals and unreferenced variables

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PyEval_GetLocals and unreferenced variables Ned Batchelder <ned@nedbatchelder.com> - 2014-12-02 06:04 -0500
    Re: PyEval_GetLocals and unreferenced variables Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-12-03 19:06 +1300

#81799 — Re: PyEval_GetLocals and unreferenced variables

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 (and thanks for listening).
>
> The behaviour of the C side is determined by certain
> settings/preferences. I want these settings to respect the Python
> scope. 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. Something like
>
>     def fun():
>        settings = Cpp_Options()
>        settings.set_some_flag()
>        cfun(settings, ...)
>        def fun2():
>            settings = Cpp_Options(settings)
>            settings.set_some_other_flag()
>            cfun(settings, ...)
>
> Then Python would automatically take care of the scope of 'settings'.
>
> However, this is difficult for the user to keep track of. So my
> idea was to allow for
>
>    def fun():
>        set_some_flag()
>        cfun(...)
>        def fun2():
>            set_some_other_flag()
>            cfun(...)
>
> I let the C side create a Cpp_Options object on the locals stack
> behind the scenes, and the 'cfun()' function takes it from there
> directly, without requiring the user to pass it. Much easier for the
> user.
>
> This works, but the problem is that the C side does not see the
> settings that were created in fun() when it gets called from fun2(). In
> fun2(), the locals do not contain objects constructed earlier in fun(),
> unless the Python side explicitly refers to them. So adding a line
>
>      settings.do_something()
>
> inside fun2() would work and forces Python to pull the settings object
> created in fun() into scope, but that sort of defeats the purpose.
>

I would use thread locals for this: 
https://docs.python.org/2/library/threading.html#threading.local

They act like global variables, in that they are available implicitly 
without being passed around, but like locals in that two separate 
threads will have different values.

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [next] | [standalone]

#81838

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web