[Stackless] Re: Stackless 3.0 for Python 2.3: new binaries

[Bob Ippolito]

On Feb 23, 2004, at 7:34 PM, Christian Tismer wrote:

> Gregor Lingl wrote:
>
>> Christian Tismer schrieb:
>>> New Win32 binaries have been uploaded to the Stackless website.
>>>
>>> Some compatibility issues with certain constructors
>>> have been solved.
>>>
>>> Please let me know of any problems.
>>>
>> Trying seriously to find out how to use stackless and what it is
>> good for ;-),
>
> Alaaf, you are cheating, right?
> You must have known, partially, last August. ;-)
>
>> I stumbled just in the beginning. While I was able to execute some of 
>> my Python programs, among them Tkinter-programs
>> and even recursive ones,
>> (1) I was not able to use Stackless from IDLE:
> ...
>
>>  >>> 3*4
>> Traceback (most recent call last):
>>   File "C:\Python23\lib\idlelib\rpc.py", line 233, in asyncqueue
>>     self.putmessage((seq, request))
>>   File "C:\Python23\lib\idlelib\rpc.py", line 322, in putmessage
>>     s = pickle.dumps(message)
>> RuntimeError: maximum recursion depth exceeded
>
> Yes, I tried this and I get the same problem.
> Have to admit that I'm not a regular IDLE user.
> Seriously, I have no idea what's going on.
> Seriously, I have also no idea why Python must
> try to pickle something, to compute 3*4 ???
>
> Everything works with Python 2.2. I expect something
> has changed dramatically with Idle, and there is some
> compatability issue with all the new pickling support that
> we had to add for Python 2.3. Eeek, how do I debug that!

This is not an authoritative response, because I don't actually know, 
however here is my guess:

(1) Python is an absolutely horrible terrible language for embedding 
(arbitrarily) inside of itself on a large scale for more reasons than I 
care to list (threads, lack of stacklessness, globals up the wazoo, 
inability to create a real subinterpreter from Python code, the fact 
that the subinterpreters from C code probably still share globals, 
etc.)
(2) GUI run loops have a long history of being especially difficult to 
integrate with one another
(3) On some platforms (like say, OS X for example) running an app 
inside of an app is not what you want to do because they will share the 
same menu bar and such.  The only time I've seen this used well is in 
Interface Builder, but you don't need to use a debugger from Interface 
Builder so the preview mode makes sense to do in-process.

Therefore the only good solution for running and debugging a Python 
program from an written-in-python IDE is to spawn a new interpreter 
process and communicate with it via some RPC mechanism and communicate 
over pipes or sockets.  In order to use debugging and smarter-than-repr 
representations of data (i.e. the IDE should let you browse objects, 
classes, etc.) it's going to have to send objects over the wire.. which 
means, pickle.

It probably took the IDLE team until Python 2.3 to figure this out, 
implement this complicated mechanism, and get it tested well enough to 
be merged with the main branch.

But I must reiterate that I have no idea.. never looked at the IDLE 
source code, don't use IDLE, haven't been on python-dev long enough to 
notice if/when this happened... I have however run into these sorts of 
problems on my own plenty of times and solved them to various degrees 
(but have not written a full out RPC mechanism, though I would like to 
at some point if a good one doesn't yet exist).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20040223/a2bdb86f/attachment.bin>