[Pythonmac-SIG] New Start Proposal: NXPython

[Jack Jansen]

On Wednesday, August 14, 2002, at 01:33 , Byron Formwalt wrote:

> MacPython enthusiasts,
>     I am proposing to head up a new effort to revamp Python for OS X.  
> This
> effort will be done in Objective-C/Cocoa, using Apple's Project 
> Builder/IB
> in the Developers' Toolkit that comes free with OS X.  There will be 
> seven
> large modules/subprojects to this major undertaking.  If anyone else has
> been waiting anxiously for this to start happening, please speak up.
> Encouragement, advice, expression of interest, and programming support 
> are
> all equally welcome.  A brief overview of the project are laid out 
> below.

Byron,
I think that you're trying to do too many things lumped together into 
one big project, whereas if you structured it as a couple of smaller 
projects you would make much more rapid progress, and it may turn out 
that some of the things don't need doing anyway. A lot of the things you 
propose are re-implementations of functionality that is already 
available to Python, in one way or another. It might not, in it's 
current form, be ideal for use on MacOSX, but in those cases I think 
your time is better spent on adapting that functionality in stead of 
starting from scratch.

> Plan of attack:
>
> 1) Design the interfaces for the Framework Python Interpreter, Framework
> Python Debugger, and External Python Frameworks.

I think this phase should start with two questions:
- What's wrong with the current interfaces
- What will I break by changing the current interfaces, and is it worth 
it.

Especially the second question is important: if you change anything 
substantial in the API that is used by Python extension modules it means 
you're cutting yourself off from all the third party extension modules 
that are out there. Jython has this problem too: there's lots more stuff 
available for Python than for Jython. And then Jython has the advantage 
that it can use Java extension modules, which your NXPython hasn't...
>
> 2) Design and implement the nxpython command-line interface tool and the
> Framework Python Interpreter.
>
> **MILESTONE 1** 31 December 2002

You're extremely optimistic here...

> 3) Design and implement NXPythonWrapper Cocoa GUI app for wrapping Un*x
> libraries into framework form, with an interface usable by NXPython.  
> (Note:
> these are not Carbon libraries specifically designed for MacPython.  
> They
> are non-X11 Un*x libraries, such as libjpeg.a or zlib.a.

First: there are a couple of tools that do this already: bgen, swig, 
pyrite and more. Second, I would guess that this was one of the 
components where you wouldn't need a GUI, or are you envisioning an 
interactive wrapping process?

If you indeed want something where you interactively steer the process: 
why not add a Cocoa front end to bgen? Bgen already knows all the 
details about passing parameters to/from C, parsing header files, etc 
etc etc. What makes it difficult to use right now is the convoluted 
procedure of finding out what all the types are, deciding whether you 
want to implement them or leave them out for now, adding the conversion 
rules, etc. An interactive front end for this would be very welcome.

> **MILESTONE 2** 30 April 2003
>
> 4) Design and implement the Framework Python Debugger and add hooks 
> into the
> nxpython tool for interactive debugging of Python scripts.

The IDE has a pretty nice debugger. It's Carbon-based, but rewriting it 
to Cocoa would be a nice exercise. And even if you do this with the 
current PyObjC bridge and not with your NXPython it should be fairly 
trivial to go from one to the other lateron.
>
> 5) Design and implement the NXPython IDE without support for generating 
> user
> apps and applets.

Same as for 4.

> **MILESTONE 3** 30 August 2003
>
> 6) Add automatic application/applet generation capability to NXPython.
> (Note:  no support is planned for making self-contained distributable
> command-line executables, since presumably, anyone using 
> command-line-only
> Python tools has Python already installed.)

Again, we have it already. Why would NXPython need a different 
BuildApplet than current Python?

> **MILESTONE 4** 30 October 2003
>
> 7) If no-one has made a good, solid, working native implementation of
> wxWindows by this point, then design and implement it.  (Hopefully this 
> will
> not be necessary.)
>
> 8) Create the NXPython accessible Framework for interfacing with 
> wxWindows,
> using the semi-automated NXPythonWrapper tool.

This is where it starts to bite you that you changed the APIs in step 
one: all the work done by other people over the year you've spent on 
this project can't be incorporated in NXPython...

All in all I think you shouldn't get carried away by too much enthusiasm 
to "do everything different". Why ont start with one of the smaller 
subprojects (I would suggest a GUI for bgen, but then I'm not 
unbiased:-) and work from there?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -