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


Groups > comp.lang.python > #81559

Re: PyEval_GetLocals and unreferenced variables

References <20141126102257.141b108f@klug> <CAPTjJmov9s=_0yVSOYSRqoCoy69vyXCKvUpScirjBQDp28Sd4A@mail.gmail.com> <20141126104628.78ed4022@klug>
Date 2014-11-26 21:51 +1100
Subject Re: PyEval_GetLocals and unreferenced variables
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.16318.1416999097.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Wed, Nov 26, 2014 at 9:46 PM, Kasper Peeters <kasper@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():
>            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.
>

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.

I wonder, would a 'nonlocal q' declaration inside fun2 affect things any?

Otherwise, maybe there's some completely different way to transfer
information around. Using locals in this way seems fraught with peril.

ChrisA

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


Thread

Re: PyEval_GetLocals and unreferenced variables Chris Angelico <rosuav@gmail.com> - 2014-11-26 21:51 +1100

csiph-web