To: python-list@python.org
From: Ned Batchelder <ned@nedbatchelder.com>
Subject: Re: PyEval_GetLocals and unreferenced variables
Date: Tue, 02 Dec 2014 06:04:20 -0500
References: <mailman.56.1417345204.28218.python-list@python.org> <20141202093510.4af9791e@tigger>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <20141202093510.4af9791e@tigger>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.16492.1417518273.18130.python-list@python.org>
Lines: 65
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!bete-des-vosges.org!feed.ac-versailles.fr!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:81799

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