|
From: Travis O. <oli...@ee...> - 2006-01-19 01:20:14
|
Alexander Belopolsky wrote: >On 1/18/06, Travis Oliphant <oli...@ee...> wrote: > > >>This mail got placed in my junk folder so I did not see it until now. >>Sorry about the confusion... >> >> >> >To add to the confusion, I've interpreted your previous e-mail as "go >ahead" and commited the changes. Hopefuly your concerns can be >addressed and I will not have to retract the change. > > > That is actually fine. I don't mind having changes in SVN that we discuss and fix. It's what its for. As long as it builds, then great... I went ahead and altered the C-API based on your desired use and changed numpy to work with it. This means that the SVN version of NumPy requires a recompilation of extension modules.... Some of my previous comments did not understand how you had implemented the routine. Hopefully what's in SVN now works correctly (it passes your tests...) >Yes, I agree and confessed to this problem in the comments to my code. > However, I did not want to touch PyArray_FromAny because it is part >of published C API. The best solution would be to expose parts of >PyArray_FromAny in C API and use those in ufunc code. > > We are pre 1.0 and so I don't have too much problems adding an extra context argument to the PyArray_FromAny call :-) I've also simplified things a bit, too. I moved array_fromobject to PyArray_FromAny and renamed PyArray_FromAny to PyArray_CheckFromAny(...) as it has a couple more checks to ensure DEFAULT_FLAGS are set when ENSURECOPY is set and to check for the NOTSWAPPED requirement... Often flags is 0 or does not have these FLAGS (or we have a native byte-order descriptor anyway and so the NOTSWAPPED requirement is redundant) and so the simpler PyArray_FromAny can be used. Most people are still using PyArray_ContiguousFromObject and friends anyway and so the change doesn't affect them at all. -Travis |