[IronPython] interpreter component

[Thane]

I have one for PythonNet written in Python that I've been trying to port to
IronPython (see attached screenshot).  You may also note that this has a
rudimentary .NET backend for matplotlib (http://matplotlib.sourceforge.net
<http://matplotlib.sourceforge.net/>  ).

 

The port has been difficult, due to the current limitations of IronPython.
After doing such an interface for Root, and then Python (both in MFC), it is
clear that the optimal solution is to write a .NET control in C# that is
_directly_ supported by IronPython.  

 

The main problem with the writers of scripting languages is that they treat
them like a compiler, and only consider stdin, stdout, and stderr streams.
All input/output is written to a CONSOLE.  If you know anything about the
Windows console you quickly realize how disastrous this is (single threaded,
non-standard i/o streams from GUI, not a Windows object, etc.).  Guido did a
good job of addressing this in Python by allowing these to be redirected
(sys.stdin = myfile), but it's clearly not enough.  I've heard rumors of a
new MS Console object in the Whidbey release. I just hope they do it right.

 

Jim - (since everyone seems to view as our "Python ambassador to
Microsoft"), perhaps you could address this in IronPython by simply having
an I/O class that initially just exposes the Console ReadLine and WriteLine
methods.  Then, people who use IronPython to write an app could have a C#
class that inherits your I/O class, and they can do whatever they want with
the I/O methods.  There also needs to be a mechanism to optionally get rid
of the Console screen, similar to PythonW.exe.

 

--Thane

 

 

  _____  

From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Keith J. Farmer
Sent: Thursday, August 19, 2004 1:26 AM
To: users-ironpython.com at lists.ironpython.com
Subject: [IronPython] interpreter component

 

Random idea --

 

Anybody manage to wrap an IronPython interpreter into a Forms control yet a
la PyCrust?  Maybe a component with an in/out/error, start/pause/reset, and
an exposed memory object that could be hooked into a textbox or the like?

 

It'd be nice to pair up the interpreter's response with the input that
triggered it, but especially in a multithreaded case, asynchronous responses
not necessarily tied to an input could occur.  I imagine this would entail a
parallel set of streams and a consumer that would route tagged output.  That
of course would require that the interpreter generate and keep track of an
input tag during processing, and cc the parallel streams.  A flagged
behavior, I think.

 

Jim -- actually, if MS promoted an interface for interpreters, it could be a
big win for plug-in scripting, you think?  They already have similar things
going on with C#, VB, and CodeDom.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20040819/39695d19/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KtLab_Screenshot_small.jpg
Type: image/jpeg
Size: 17392 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20040819/39695d19/attachment.jpg>