<br><br><div class="gmail_quote">On Mon, Oct 17, 2011 at 8:29 AM, Ian Ozsvald <span dir="ltr"><<a href="mailto:ian@ianozsvald.com">ian@ianozsvald.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> This would be very useful since<br>
> you don't need to use Cython or any other things like this to provide<br>
> working code and it already caters for some group of people.<br>
<br>
</div>Hi Fijal. This would be useful for a demo - but will it be useful for<br>
the userbase that becomes motivated to integrate Cython and SciPy?<br>
<br>
If it isn't useful to the wider community (which is the point I've<br>
made after David's email) then aren't we creating a (potentially)<br>
dead-end project rather than one that opens the doors to increased<br>
collaboration between the communities?<br>
<br>
Perhaps I should ask a wider question: If the pypy-numpy project only<br>
supports the core features of numpy and not the API (so excluding<br>
Cython/SciPy etc for now), what's the roadmap that lets people<br>
integrate SciPy's C/Fortran code in a maintainable way? I.e. how is<br>
the door opened to community members to introduce SciPy compatibility?<br>
Some idea of the complexity of the task would be very useful,<br>
preferably with input from people involved with CPython's numpy/scipy<br>
internals.<br>
<div class="im"><br>
i.<br>
<br>
--<br>
Ian Ozsvald (A.I. researcher)<br>
ian@IanOzsvald.com<br>
<br>
<a href="http://IanOzsvald.com" target="_blank">http://IanOzsvald.com</a><br>
<a href="http://MorConsulting.com/" target="_blank">http://MorConsulting.com/</a><br>
<a href="http://StrongSteam.com/" target="_blank">http://StrongSteam.com/</a><br>
<a href="http://SocialTiesApp.com/" target="_blank">http://SocialTiesApp.com/</a><br>
<a href="http://TheScreencastingHandbook.com" target="_blank">http://TheScreencastingHandbook.com</a><br>
<a href="http://FivePoundApp.com/" target="_blank">http://FivePoundApp.com/</a><br>
<a href="http://twitter.com/IanOzsvald" target="_blank">http://twitter.com/IanOzsvald</a><br>
</div><div><div></div><div class="h5">_______________________________________________<br>
pypy-dev mailing list<br>
<a href="mailto:pypy-dev@python.org">pypy-dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">http://mail.python.org/mailman/listinfo/pypy-dev</a><br>
</div></div></blockquote></div><br>Let me ask the opposite question: What route do you envision that gives us both the speed we (and everyone else) desires, while not having any of these issues? That's not a question that has a very good answer I think. We could bring CPyExt up to a point where NumPy's C code runs, but that would be slow and a royal pain in the ass. What's the other alternative? We could port all of NumPy to be pure Python + wrapping code only for existing C/Fortran libraries. To be honest, that sounds very swell to me, would the core-numpy people go for that? Of course not, because it would be heinously slow on CPython, which I presume is unacceptable. So where does that leave us? Neither of the current platforms seems acceptable, what's the way forward where we're all in this together, because I'm having trouble seeing that (especially if, as Travis's post indicates backwards compatibility within NumPy means that none of the C APIs can be removed).<div>
<br></div><div>Alex<br clear="all"><div><br></div>-- <br>"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>"The people's good is the highest law." -- Cicero<br>
<br>
</div>