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


Groups > comp.lang.python > #81799

Re: PyEval_GetLocals and unreferenced variables

From Ned Batchelder <ned@nedbatchelder.com>
Subject Re: PyEval_GetLocals and unreferenced variables
Date 2014-12-02 06:04 -0500
References <mailman.56.1417345204.28218.python-list@python.org> <20141202093510.4af9791e@tigger>
Newsgroups comp.lang.python
Message-ID <mailman.16492.1417518273.18130.python-list@python.org> (permalink)

Show all headers | View raw


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

Back to comp.lang.python | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

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

csiph-web