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),
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
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
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
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
> On 30 May 2023, at 21:10, James Schaffler via Python-list
> wrote:
>
> Originally posted to idle-dev, but thought this might be a better place. Let
> me know if it isn't.
>
> Hi,
>
> I was curious about the internals of IDLE, and noticed that IDLE uses
> executes user code in a
