[Pythonmac-SIG] RE: New Start Proposal: NXPython

[Ronald Oussoren]

Byron,

I'm not sure how usefull this project will be, it will probably be an 
awfull lot of work with at most minor benefits w.r.t. the default python 
implementation. If you want to access existing objective-C frameworks 
you can do some with PyObjC (pyobjc.sourceforge.net). The existing 
release is a bit limited, but we're working on an improved version (see 
http://www.cistron.nl/~oussoren/pyobjc for a pre-pre-release)

Greetings,
	Ronald


On Wednesday, August 14, 2002, at 05:49 , Byron Formwalt wrote:

> Objective-C Advocacy:
>
> I should point out two important distinctions between the proposed 
> NXPython
> and existing Python implementations.  NXPython will adhere to every 
> letter
> of the Python language.  However, it will have a radically different API
> than the current open source Python implementations share.  For one, 
> the API
> will be in Objective-C.  This is why I mentioned the need to provide the
> semi-automated wrapping utility.  Obj-C enthusiasts wishing to write new
> modules may do so with ease, using Apple's modified gcc to extending
> NXPython with Obj-C frameworks.  At the same time, this does not 
> preclude
> traditional users from auto-wrapping their existing legacy extensions.
> Since Cocoa is only available to Java and Obj-C programmers, this seemed
> like the most reasonable path to take for future Python implementations 
> on
> the Mac.  While Python could remain only in C, it makes more sense to 
> take
> advantage of the inherent objective nature in Obj-C to implement the
> objective nature of Python.
>
> Objective-C Portability:
>
> The other thing I wanted to point out, in case some may not be aware, is
> that the Obj-C source code for GCC compiler is available at GNU, and has
> been successfully compiled for Linux, Un*x, cgwin, and of course, Mac 
> OS X.
> This means that the nxpython command-line interface, API, and 
> interpreter
> can be made open source, also.  The only question of portability is
> specifying the build type based on the build platform.  Frameworks 
> would be
> DLLs on windows, and on the Un*x flavored machines, non-framework 
> options
> would need to be provided.  While I'm not planning to make this
> implementation port over to the other platforms, I don't want to stand 
> in
> the way of someone who really wants to do it.
>
> The Obj-C version of GCC is at
> ftp://ftp.cis.ohio-state.edu/mirror/gnu/gcc/gcc-3.1.1/gcc-
> objc-3.1.1.tar.gz
>
> Byron
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>