On Tuesday, May 30th, 2023 at 10:18 PM, Chris Angelico wrote:
> Yep, what you're seeing there is the namespace and nothing else. But
> if you mess with an actual builtin object, it'll be changed for the
> other interpreter too.
>
> > > > import ctypes
> > > > ctypes.cast(id(42), ctypes.POINTER(cty
On Wed, 31 May 2023 at 12:03, James Schaffler via Python-list
wrote:
>
> On Tuesday, May 30th, 2023 at 9:14 PM, Greg Ewing wrote:
> > Globals you create by executing code in the REPL have their own
> > namespace. But everything else is shared -- builtins, imported
> > Python modules, imported C ex
On Tuesday, May 30th, 2023 at 9:14 PM, Greg Ewing wrote:
> Globals you create by executing code in the REPL have their own
> namespace. But everything else is shared -- builtins, imported
> Python modules, imported C extension modules, etc. etc.
Thanks for the explanation. Could you elaborate on p
On 29/05/23 8:10 am, James Schaffler wrote:
However, some minimal testing of InteractiveInterpreter leads me to believe
that the Interpreter object has its own view of local/global variables and
therefore shouldn't be able to affect the calling interpreter
Globals you create by executing code
On Wed, 31 May 2023 at 08:16, Barry wrote:
> I don’t think it security but robustness that needs the subprocess.
>
> Also if your code use tk then it would conflict with idle’s use of tk.
>
From my memory, it's precisely this - it's much MUCH easier to allow
you to use Tk in your own program with
own view of
> local/global variables and therefore shouldn't be able to affect the calling
> interpreter (please correct me if I'm wrong).
>
> So my question is a combination of "Why does IDLE use a subprocess?" and "Why
> is InteractiveInterpreter not secur
rom IDLE itself." However, some minimal testing of InteractiveInterpreter
leads me to believe that the Interpreter object has its own view of
local/global variables and therefore shouldn't be able to affect the calling
interpreter (please correct me if I'm wrong).
So my question
