Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.016 X-Spam-Evidence: '*H*': 0.97; '*S*': 0.00; 'though:': 0.07; 'cc:addr :python-list': 0.11; 'python': 0.11; 'def': 0.12; 'mostly': 0.14; "wouldn't": 0.14; "'q'": 0.16; 'code?': 0.16; 'kasper': 0.16; 'all.': 0.16; 'do.': 0.18; 'library': 0.18; 'example': 0.22; 'cc:addr:python.org': 0.22; 'space.': 0.24; 'fairly': 0.24; 'cheers,': 0.24; 'cc:2**0': 0.24; 'pass': 0.26; 'header:In-Reply- To:1': 0.27; "doesn't": 0.30; 'convince': 0.31; 'skip:c 30': 0.32; 'older': 0.33; 'agree': 0.35; 'something': 0.35; 'but': 0.35; 'there': 0.35; 'charset:us-ascii': 0.36; 'little': 0.38; 'simply': 0.61; 'more': 0.64; 'to:addr:gmail.com': 0.65; 'within': 0.65; 'side': 0.67; 'natural': 0.68; 'tricky': 0.84 Date: Wed, 26 Nov 2014 10:46:28 +0000 From: Kasper Peeters To: Chris Angelico Subject: Re: PyEval_GetLocals and unreferenced variables In-Reply-To: References: <20141126102257.141b108f@klug> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "python-list@python.org" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 33 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1416998820 news.xs4all.nl 2969 [2001:888:2000:d::a6]:33906 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:81558 > > 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 > > local scope from within my C code? > > Wouldn't this be a little surprising? Why not simply pass q as a > parameter? 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(): 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 have fairly good reasons to do things this way, mostly having to do with historical constraints of an older C library that I cannot avoid), but it requires more space. Cheers, Kasper