pygame and python 2.5

[Hendrik van Rooyen]

"Steve Holden" <steve at holdenweb.com>

> Hendrik van Rooyen wrote:
> > <skip at pobox.com> wrote:
> > "Ben Sizer" <kylotan at gmail.com> wrote:
> > 
> > 
> >>     Ben> Python extensions written in C require recompilation for each new
> >>     Ben> version of Python, due to Python limitations.
> >>
> >> Can you propose a means to eliminate this limitation?
> >>
> > 
> > Yes.   - Instead of calling something, send it a message...
> > 
> I suppose you are proposing to use the ISO 19999.333 generic 
> message-passing interface for this? The one that doesn't actually call a 
> function to pass a message?
> 

Actually I am not aware that this ISO standard exists.

My feeling about ISO standards in general are such that 
I would rather have *anything* else than an ISO standard.
These feelings are mainly caused by the frustration of trying
to decipher standards written in standardese, liberally sprinkled
with non standard acronyms...

Its very interesting to learn that you can pass a message without
doing a call - when I next need to entertain a children's party as a
magician I will endeavour to incorporate it into my act.  Thanks 
for the tip.

But more seriously, the concept is that you should couple
as loosely as possible, to prevent exactly the kind of trouble
that this thread talks about.  Just as keyword parameters are
more robust than positional parameters, the concept of doing
something similar to putting a dict on a queue, is vastly more 
future-proof than hoping that your call will *get through*
when tomorrow's compiler buggers around with the calling 
convention.

One tends to forget that calling also builds messages on 
the stack.

When you boil it right down, all you need for a minimalistic
interface are four message types:

- get something's value
- set something to a value
- return the requested value
- do something  

This is not the most minimalistic interface, but its a nice 
compromise.

The advantages of such loose coupling are quite obvious when 
you think about them, as you don't care where the worker sits -
on the other side of the world over the internet, or in the same 
room in another box, or in the same box on another processor, 
or on the same processor in another process, or in the same 
process in another thread...

The problem with all this, of course, is the message passing 
mechanism, as it is not trivial to implement something that
will address all the cases. A layered approach (ISO ?  ; - )  )
could do it...

But Skip asked how to sort it, and this would be 
My Way.   (TM circa 1960 F Sinatra)

- Hendrik