Why GIL? (was Re: what's the point of rpython?)

[Steve Holden]

Carl Banks wrote:
> On Jan 23, 8:22 pm, Bryan Olson <fakeaddr... at nowhere.org> wrote:
>> Paul Rubin wrote:
>>> Bryan Olson writes:
>>>>> BTW, class instances are usually immutable and thus don't require a
>>>>> mutex in the system I described.
>>>> Then you are describing a language radically different from Python.
>>> That one threw me for a minute too, but I think the idea is that the
>>> class instance itself is immutable, while its slots (specifically the
>>> attribute dictionary) point to mutable objects.
>> The meaning of 'immutable' is well-established in the Python literature.
>> Python's immutable types include tuple, frozenset, and various kinds of
>> numbers and strings. Class instances, not so much.
> 
> Of course class instances aren't immutable types: they're not even
> types.  Let me suggest that there is a distinction between an
> immutable type and an immutable object.
> 
> Immutable types are what you are talking about: it means that the type
> provides usable mutator methods.  (Whether they mutate the object
> itself or some associated object doesn't matter.)  Immutable objects
> are a different thing: it means the object cannot change in memory.
> 
> Classes in Python are mutable types, usually.  Class instances are
> (except for the refcount) immutable objects, usually.
> 
> We usually talk about mutability of types, but mutability of objects
> is appropriate for discussion as well.  So I can't really agree with
> your assessment that I wrong to call class instances immutable objects
> aside from refcounts.
> 
> BTW, here's a minor brain bender: immutable types are mutable objects.
> 
> 
>> What's more, this matters when considering a GIL-less implementation.
>> Typical method calls can traverse lots of mutable stuff just to find the
>> function to invoke.
> 
> Now that doesn't make sense at all.  What is all this mutable stuff
> you have to go through, and what does it have to do with the GIL-less
> implementation?  Can you explain further?  Or are you just saying
> it'll be slow.
> 
OK, so we have recently discussed whether objects are values, whether
function arguments are passed by reference, whether names are
references, and now we are, I suspect, about to have a huge further
discussion on the meaning of "immutable".

Sometimes I start to find this eternal pedantry a little tedious. I
suspect it's time I once more dropped out of c.l.py for a while.

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/