[Numpy-discussion] 1.6: branching and release notes

[Ralf Gommers]

On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
>>
>> On Sun, Mar 13, 2011 at 8:23 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
>>>
>>> On Sun, Mar 13, 2011 at 1:22 AM, Ralf Gommers
>>> <ralf.gommers at googlemail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag the
>>>> first beta. So please get your last commits for 1.6 in by Monday
>>>> evening.
>>>>
>>>> Also, please review and add to the 1.6.0 release notes. I put in
>>>> headers for several items that need a few lines in the notes, I hope
>>>> this can be filled in by the authors of those features (Charles:
>>>> Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch of
>>>> stuff).
>>>
>>> I've added a few more things, and made a small change to the iterator
>>> construction API that I've discovered is useful, but would be more difficult
>>> to do later. The Python exposure of the iterator is renamed from 'newiter'
>>> to 'nditer', is that a reasonable name or does anyone have a better
>>> suggestion?
>>
>> I think nditer is fine, certainly better than newiter. I don't see where
>> nditer appears in the changes though, the test still uses newiter.
>
> I didn't rename the files, I can do that too.

Hi Mark, I see you just did this, but is there anything else you
want/need to do? If it's necessary I can postpone the first beta by a
couple of days. Better that than rush things too much and end up with
an API you have reservations about.

Cheers,
Ralf


>> On the arr_ravel_coords name and the python exposure of same, I've been
>> thinking ravel_fancyindex might be more suggestive than ravel_coords.
>
> Hmm, that doesn't seem quite right to me, it implies something fancier about
> it than I think it actually is. Maybe the ideal would be to have it be
> ravel_index/unravel_flatindex, but the unravel_index function already
> existed as precedent. On the other hand, in lots of contexts just saying
> "index" sounds like it should be one number, not a tuple, which is why in
> the iterator API the "index" usage refers to a C or Fortran-order flat
> index. Of the options we've considered so far, probably ravel_multiindex is
> my favorite, though nothing has really stood out.
> -Mark
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>