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


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

Re: PyEval_GetLocals and unreferenced variables

Started byChris Angelico <rosuav@gmail.com>
First post2014-11-26 21:51 +1100
Last post2014-11-26 21:51 +1100
Articles 1 — 1 participant

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 Chris Angelico <rosuav@gmail.com> - 2014-11-26 21:51 +1100

#81559 — Re: PyEval_GetLocals and unreferenced variables

FromChris Angelico <rosuav@gmail.com>
Date2014-11-26 21:51 +1100
SubjectRe: PyEval_GetLocals and unreferenced variables
Message-ID<mailman.16318.1416999097.18130.python-list@python.org>
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

[toc] | [standalone]


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


csiph-web