[Pythonmac-SIG] New Start Proposal: NXPython
Jack Jansen
Jack.Jansen@cwi.nl
Wed, 14 Aug 2002 11:16:17 +0200
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 -