[Python-Dev] Parrot -- should life imitate satire?

[Paul Prescod]

Dan Sugalski wrote:
> 
>...
> 
> Is this global in the "all variables are in one big pool and can be looked
> up by name", more or less the equivalent of externing all your C variables,
> or global in the "Any thread might be able to see it" sense? (I thought
> Python had lexically scoped variables, but I might be wrong here. I'm an
> internals guy--the actual language being run is just an implementation
> detail... :)

Python certainly has HIGHLY SCOPED variables. Hardly anything is global
in that sense. Even a two-line script will not really have truly global,
global variables. I wasn't so happy with Aahz's choice of wording there.
:)

Only the namespace of module names is truly global. i.e. "import sys"
gets you the same module object everywhere so you can use modules as
containers for other kinds of globals.

> If it's "All objects are visible to all threads" thing, that's fine, you
> can still handle threading with some care. Perl's done it wrong once, and I
> know how to do it much less wrong with Parrot. (It's not, strictly
> speaking, possible to do it right without the programmer taking an active hand)

Agreed.

>...
> >And, as Paul pointed out, the global interpreter lock only kills you if
> >you're running SMP in the first place.
> 
> Yep, well, I do. :)

Still, I would encourage you to optimize for the common case. People
have been predicting multiprocessor would be the common case for years
but Moore's law keeps delaying the need to pump up all of our servers
with a dozen processors.

The Python threading model is one interpreter for all threads unless you
really need multiple interpreters in which case you are sort of on your
own.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook