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

[Aahz Maruch]

Dan Sugalski wrote:
> At 05:04 PM 7/31/2001 -0700, Aahz Maruch wrote:
>>Dan Sugalski wrote:
>>>
>>> As for threading, well, that's where things get interesting. Perl's
>>> tried it two ways (multiple threads in the same interpreter, and one
>>> thread per interpreter, with cloned interpreters) both of which aren't
>>> very good. And the global lock thing's not that keen either. The plan
>>> for parrot is to allow multiple interpreters to run simultaneously,
>>> with shared data protected on access time. (And *only* shared data
>>> protected, so there's no penalty to access non-shared data) Along with
>>> a scheme to allow only partial (or no) visibility of the spawning
>>> thread's variables. We plan on basing the secure sandbox scheme around
>>> this as well.
>>
>>This is where calling what Python uses "variables" gets you into real
>>problems.  Many people think that the terms for "variable" and
>>"reference" should be "name" and "binding"; it makes things far less
>>confusing.
> 
> I'm not sure that's the appropriate translation for what perl considers 
> variables and references, but that's OK.

Paul evidently disagrees with me, but I'll write a rebuttal to that
right after I finish this.  ;-)

>>See, Python objects are *global*.  Period.  No ifs, ands, or
>>buts.
> 
> 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... :)

Somewhere in between.  Python names are scoped; Python objects are not.
Here's a trival example: given a global list "l" (and "global" in this
phrase almost always means "module global"), and the following code
fragment running in one thread

    def foo():
        x = 1
        l.append(x)

any other threads created in that module will immediately have access to
the locally-created object "1".

Beyond that, though, given Python's introspection capabilities, it is
theoretically correct to say that all variables can be looked up by
name.

> 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)

Yup.  Which is why the GIL represents a pretty good compromise, most of
the time, particularly the way it's implemented in Python.

>>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. :)

Should have added, "...and only if you're running pure Python code."
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6       <*>       http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

I don't really mind a person having the last whine, but I do mind someone 
else having the last self-righteous whine.