[Numpy-discussion] indexed increment (was Re: Pull Requests I'm planning to merge)
Thu Jul 19 04:56:33 CDT 2012
On Thu, Jul 19, 2012 at 6:04 AM, Frédéric Bastien <email@example.com> wrote:
> On Tue, Jul 17, 2012 at 10:20 PM, Travis Oliphant <firstname.lastname@example.org> wrote:
>> 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!)
Really I'm making two points:
1- this design smells just "off" enough that we should discuss it to
figure out whether or not it's actually the best way forward.
2- such discussions are too important to just skip whenever a release
is imminent. there will be another release...
> 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.
The "NumPy 2" idea is not very realistic IMHO, and shouldn't be used
as an excuse for being sloppy. We're never going to be able to go
through and make all the APIs perfect in one release cycle. Especially
if we keep deferring all hard questions until then.
> So in conclusion, can we say that when John will have make is PR work
> with all dtype, we merge it?
Well, we'll come up with something :-). (Assuming that people stay
interested, which seems likely since this is such a common problem
people have.) But I'm not sure what. Making the PR work with all
dtypes is exactly what Travis is arguing is too much work.
> Also, I understood that it won't be
> included in NumPy 1.7. Is that right?
More information about the NumPy-Discussion