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

[Carl Banks]

On Jan 24, 12:40 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Sat, 24 Jan 2009 06:06:02 -0200, Carl Banks <pavlovevide... at gmail.com>  
> escribió:
>
>
>
> > On Jan 23, 11:45 pm, Bryan Olson <fakeaddr... at nowhere.org> wrote:
> >> Carl Banks wrote:
> >> > Classes in Python are mutable types, usually.  Class instances are
> >> > (except for the refcount) immutable objects, usually.
>
> >> There's where we disagree. I assert that class instances are usually
> >> mutable objects.
>
> > Nope, you're dead wrong, nothing more to it.  The bits of a class
> > instance never change.  The __dict__ is a mutable object.  The class
> > instance itself isn't.  It's not reasonable to call an object whose
> > bits can't change a mutable obect.
>
> > Anyway, all you're doing is distracting attention from my claim that
> > instance objects wouldn't need to be locked.  They wouldn't, no matter
> > how mutable you insist these objects whose bits would never change
> > are.
>
> Me too, I don't get what you mean. Consider a list instance, it contains a  
> count of allocated elements, and a pointer to some memory block. They  
> change when the list is resized. This counts as "mutable" to me. I really  
> don't understand your claim.


Yeah, yeah, I know that, and in the bickering that ensued some aspects
of the original context were lost.  I should really not have been
pulled into Bryan's strawman over the definition of immutable, since
it's just a label, I oughtn't give a damn what it's called, I only
care what it does.  I didn't handle this repartee very well.

Anyway, it goes back to the original vision for a mark-and-sweep
Python language as I presented what seems like a long time ago.

I presented the type system that had three base metatypes instead of
the one base metatype we have now: immutable_type, mutable_type, and
mutable_dict_type.  The default metatype for Python classes would be
mutable_dict_type, which is a type wherein the object itself would be
mutable but it would still have all the mutator methods __init__,
__setattr__, etc., but they could only act on the __dict__.
mutable_dict_types would not be allowed to define any slots, and
__dict__ wouldn't be reassignable.  (However, it seems reasonable to
allow the base tp_new to accept a dict argument.)

OTOTH, list's metatype would be mutable_type, so the type object
itself would be mutable.

Bryan claimed that that would be a very different language from
Python, apparently because it hadn't occurred to him that by-and-
large, the instance itself doesn't change, only the dict does.
Perhaps Bryan was thinking of __dict__'s reassignability (that
certainly didn't occur to me); if he was I apologize for my snideness.

HAVING SAID THAT, I still still say what I proposed would not be a
radically different language from Python.  A little different, of
course.  Much slower, almost certainly.


Carl Banks