<div class="gmail_quote">On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers <span dir="ltr"><<a href="mailto:ralf.gommers@googlemail.com">ralf.gommers@googlemail.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"><snip></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
>>> I've had a look at the bug tracker, here's a list of tickets for 1.6:<br>
>>> #1748 (blocker: regression for astype('str'))<br>
>>> #1619 (issue with dtypes, with patch)<br>
>>> #1749 (distutils, py 3.2)<br>
>>> #1601 (distutils, py 3.2)<br>
>>> #1622 (Solaris segfault, with patch)<br>
>>> #1713 (Solaris segfault)<br>
>>> #1631 (Solaris segfault)<br>
<br>
</div></div>The distutils tickets are resolved.<br>
<div class="im"><br>
>>> Proposed schedule:<br>
>>> March 15: beta 1<br>
>>> March 28: rc 1<br>
>>> April 17: rc 2 (if needed)<br>
>>> April 24: final release<br>
<br>
</div>Any comments on the schedule or tickets?<br></blockquote><div><br></div><div>That all looks fine to me. There are a few things that I've changed in the core that could stand some discussion before being finalized in 1.6, mostly due to what was required to make things work without depending on the data type enumeration order. The combination of the numpy and scipy tests were pretty effective, but as Travis mentioned my changes are fairly invasive.</div>
<div><br></div><div>* When copying array to array, structured types now copy based on field names instead of positions, effectively behaving like a 'dict' instead of a 'labeled tuple'. This behaviour is more intuitive to me, and several fixed bugs such as dtype comparison completely ignoring the structured type data suggest that this changes an area of numpy that has been used in a more limited fashion. It might be worthwhile to introduce a tuple-style flag in a future version which causes data to be copied by position instead of by name, as it is likely useful in some contexts.</div>
<div><br></div><div>* Array memory layouts are preserved in many cases. This means that if a, b are Fortran ordered, a+b will be as well. It could be made more pervasive, for example ndarray.copy defaults to C-order, and that could be changed to 'K' to preserve the memory layout by default. Any comments about that?</div>
<div><br></div><div>* The ufunc uses a more consistent algorithm for loop selection. The previous algorithm was ad hoc and lacked symmetry, while the new algorithm is based on a simple minimization definition. This change exposed a bug in scipy's ndimage, which did not handle all of the numpy data type enums properly, so its possible there is more code out there which will be affected similarly.</div>
<div><br></div><div>In general, I've used the implementation strategy of substituting my code into the core critical paths of numpy to maximize the amount of exercise it gets. While this creates more short-term hiccups as we are seeing now, it also means the new functionality conforms to the current system better and is much more stable since it is getting well tested.</div>
<div><br></div><div>-Mark</div></div>