[Numpy-discussion] Pull Requests I'm planning to merge

Frédéric Bastien nouiz@nouiz....
Thu Jul 19 00:04:53 CDT 2012


Hi,

On Tue, Jul 17, 2012 at 10:20 PM, Travis Oliphant <travis@continuum.io> wrote:
>
> On Jul 17, 2012, at 6:48 PM, Nathaniel Smith wrote:
>
>> On Tue, Jul 17, 2012 at 9:56 PM, Travis Oliphant <travis@continuum.io> wrote:
>>>
>>> I would like to merge the following pull requests sometime today:
>>>
>>> * 326 -- inplace increment function
>>
>> -1, for the reasons stated in the comment thread -- we shouldn't lock
>> ourselves into an ugly API when there's discussion going on about the
>> right solution, and the submitter has expressed interest in rewriting
>> it in a better way. Also to be clear, I'm not saying I will try to
>> block this functionality forever unless it's perfect or anything -- I
>> could probably be convinced that putting in something sub-optimal here
>> was the best trade-off. Really what I'm -1 on is shoving something in
>> without proper discussion just because the release is happening, on
>> the theory that we can clean up any mess later. Until your comment a
>> few hours ago no-one even looked at this new API except me and the
>> submitter...
>
> You are incorrect about that.  I've looked at it several times since it was posted.   I've looked at and studied all the PRs multiple times in fact over the past several months.  I've waited for others to express an opinion.  I don't think it's accurate to assume that people have not seen something because they don't comment.
>
> I will hold off on this one, but only because you raised your objection to -1 (instead of -0.5).    But, I disagree very strongly with you that it is "sub-optimal" in the context of NumPy.   I actually think it is a very reasonable solution.   He has re-used the MapIter code correctly (which is the only code that *does* fancy indexing).   The author has done a lot of work to support multiple data-types and satisfy an often-requested feature in a very reasonable way.  Your objection seems to be that you would prefer that it were a method on ufuncs.  I don't think this will work without a *major* refactor.  I'm not sure it's even worth it then either.

Due to Travis comments, I expect the "better" solution won't be done
in the short time. So blocking a feature requeted frequently because
we could do sometimes in an unknow futur something better is not a
good idea. (if I get it wrong on the expectation, please, correct me!)
Also, if we decide to change the interface, we could do it for NumPy
2, so I don't see a need for an infinit time support of this API.

So in conclusion, can we say that when John will have make is PR work
with all dtype, we merge it? Also, I understood that it won't be
included in NumPy 1.7. Is that right?

Fred


More information about the NumPy-Discussion mailing list