Hernan M Foffani wrote:
Definetly it's a huge work.
Which module should we go for? NumPy looks like a good start, as it gives
us a start on getting SciPy working. But perhaps there are better choices.
Should this be a new project, or should we be talking to other people about
getting it into other projects?
NumPy is already big. I'd start with a very small project like the
sample at http://docs.python.org/ext/simpleExample.html. Sort of a
proof of concept.
We will pick a starting project, that although possibly big, will
provide some direct 'business value' when completed.
However your suggestion is not a bad way of starting that project
(depending on which approach we take of course).
Have you evaluated that you may need to port a big portion of the Python
C API (Py* functions and macros.)?
Yes. :-)
What is the best architecture? We're thinking of this as being a bit of C#
managed code to interface with the C extension, and a thin Python wrapper on
top. The module's existing C extension and Python code would sandwich
this layer. Let us know if this is a silly idea :-)
As someone else already said, you ought to consider COM too.
Another aproach is to completly forget the *CPython* extension. Pick
the domain C code core and add a .NET wrapper. Swig can you help here:
http://www.swig.org/tutorial.html
In these two approaches a Python compatibility layer API will be needed.
Thus, the programmer can use the same API from IronPython that she
used to use from CPython.
Both interesting possibilities - thanks.
Michael
http://www.manning.com/foord
Is there anything else we should be thinking about to get this started?
Hummm... I'm tempted to add a silly joke here but I'm going to refrain
myself now. ;)
Regards,
-Hernán.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
