what's the point of rpython?

[Tim Rowe]

Whatever sufficiently sophisticated topic was the initially discussed
it ends all up in a request for removing reference counting and the
GIL.

Well, maybe, but it seems to me that the real issue here is that we
need to remove reference counting and the GIL.

 

[skip]

Steve> Indeed it would, but hey, let's not let that stop us repeating
Steve> the thinking that's gone into CPython over the last fifteen
Steve> years. "Those who cannot remember the past are condemned to
Steve> repeat it".

Also, every object is mutable at some level. Tuples, ints and floats are
definitely mutable at creation time. You need to hold a mutex then, so
Carl's notion of three types of objects breaks down then.

Skip

 

[Tim Rowe]

BTW, he said sufficiently sophisticated topic. Since there hasn't been an
extremely long post here yet, I don't know if this counts.

Had I waited until the thread became long enough, somebody else would
have already raised the issue -- you must surely know about Schluehr's
Law? ;-)

 

[Paul Rubin]

Also, every object is mutable at some level. Tuples, ints and floats are
definitely mutable at creation time. You need to hold a mutex then, so
Carl's notion of three types of objects breaks down then.

Hopefully, at creation time, they will usually be in a scope where
other threads can't see them.

 

[Rhamphoryncus]

On Jan 22, 6:00 am, (e-mail address removed) (Aahz) wrote:

IMO, locking of the object is a secondary problem.  Python-safethread
provides one solution, but it's not the only conceivable one.  For the
sake of discussion it's easier to assume somebody else is solving it
for you.

That assumption might be good for the sake of the discussion *you*
want to have, but it's not for discussion I was having, which was to
address Aahz's claim that GIL makes extension writing simple by
presenting a vision of what Python might be like if it had a mark-and-
sweep collector.  The details of the GC are a small part of that and
wouldn't affect my main point even if they are quite different than I
described.  Also, extension writers would have to worry about locking
issues here, so it's not acceptable to assume somebody else will solve
that problem.

Instead, focus on just the garbage collection.

[snip rest of threadjack]

You can ignore most of what I was talking about and focus on
technicalities of garbage collection if you want to.  I will not be
joining you in that discussion, however.

Carl Banks

I'm sorry, you're right, I misunderstood your context.

 

[Hrvoje Niksic]

Unfortunately, references on the stack would need to be registered
as well, so "PyObject* p;" might have to be replaced with something
like "Py_DECLARE_REF(PyObject,p);" which magically registers it.
Ugly.

Not only registered at the beginning of the function, but also (since
CPython uses C, not C++) explicitly unregistered at every point of
exit from the function. Emacs implements these as macros called GCPRO
and UNGCPRO, and they're very easy to get wrong. In a way, they are
even worse than the current Python INCREF/DECREF.

See description at, for example,
http://www.xemacs.org/Documentation/beta/html/internals_19.html#SEC78

 

[Carl Banks]

    >> You mean every time you access a list or dictionary or class
    >> instance, you have to acquire a mutex?  That sounds like a horrible
    >> slowdown.

    Steve> Indeed it would, but hey, let's not let that stop us repeating
    Steve> the thinking that's gone into CPython over the last fifteen
    Steve> years. "Those who cannot remember the past are condemned to
    Steve> repeat it".

Also, every object is mutable at some level.  Tuples, ints and floats are
definitely mutable at creation time.  You need to hold a mutex then, so
Carl's notion of three types of objects breaks down then.

immutable_type objects wouldn't exist at all until their
PyWhatever_New or their tp_new member is called. After that, the
reference exists only on the local stack, which is accessible only to
one thread. As long as you finish initializing the object while it's
still only on the stack, there is no possibility of a conflict.

What about tp_init, then, you ask? Well it's simple: immutable_type
doesn't call it. In fact, it requires that tp_init, tp_setattro,
tp_mapping->mp_setitem, etc., are all null.

immutable_obejcts have no instance dict, so if you want to create
attributes in Python you have to use slots. immutable_object.__new__
accepts keyword arguments and initializes the slots with the value.

class Record(immutable_object,slots=['name','number']):
def __new__(cls,name):
number = db.lookup_number(name)
immutable_object.__new__(cls,name=name,number=number)


Carl Banks

 

[Steve Holden]

Rhamphoryncus wrote:
[... eighty-eight quoted lines ...]

I'm sorry, you're right, I misunderstood your context.

Perhaps you could trim your posts to quote only the relevant context?
Thanks.

 

[Martin P. Hellwig]

Well, maybe, but it seems to me that the real issue here is that we
need to remove reference counting and the GIL.

Perhaps, but you could also say that if it was that widely discussed and
still not changed that it was for a *good* reason, perhaps the reason
may change over time but at this moment it is still a good reason.

Or you can argue that even when an argument is repeated indefinitely it
doesn't make it suddenly right.

 

[Terry Reedy]

Well, maybe, but it seems to me that the real issue here is that we
need to remove reference counting and the GIL.

Guido will give up reference counting and the consequent immediate gc
when but only when *someone* presents an implementation that does and
and that runs faster. Given the current ferment in dynamic language
implementation, he just today wrote on pydev list "CPython's
implementation strategy *will* evolve". Whether that means R.C. goes
away or not remains to be seen.

 

[Tim Rowe]

Or you can argue that even when an argument is repeated indefinitely it
doesn't make it suddenly right.

No, but it makes for a confirmation of Schluehr's law

 

[Bryan Olson]

Carl Banks wrote:
[...]

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.

 

[Carl Banks]

Carl Banks wrote:

[...]

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.

Bzzt.

Hint: aside from the reference count, most class instances are
immutable in Python *today*.


Carl Banks

 

[Paul Rubin]

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.

 

[Steven D'Aprano]

Carl Banks wrote:

[...]

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.

Bzzt.

Hint: aside from the reference count, most class instances are immutable
in Python *today*.

That seems so utterly wrong that either you're an idiot or you're talking
at cross purposes to what Bryan and I think you're saying. Since I know
you're not an idiot, I can only imagine you have a different
understanding of what it means to be immutable than I do.

For example... is this instance immutable?

class Foo:
bar = None

f = Foo()
f.baz = True



If so, what do you mean by immutable?

 

[Paul Rubin]

For example... is this instance immutable?

class Foo:
bar = None

f = Foo()
f.baz = True
If so, what do you mean by immutable?

If I understand Carl, yes, f is immutable. When you set f.bar, the
contents of f.__dict__ changes but f itself does not change. It still
points to the same dictionary, etc.

 

[Bryan Olson]

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.

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.

 

[Carl Banks]

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.

Correct, and, getting back to the point, an instance itself would not
require a mutex. The dict would need it, of course.

It's customary to gloss over this technicality for convenience's sake
in most discussions, but it matters in this case.


Carl Banks

 

[Paul Rubin]

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.

But we are talking about objects as they live in the C implementation,
not at the level where Python code deals with them.

 

[Carl Banks]

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.


Carl Banks