indexed increment (was Re: Pull Requests I'm planning to merge)
On Thu, Jul 19, 2012 at 6:04 AM, Frédéric Bastien
On Tue, Jul 17, 2012 at 10:20 PM, Travis Oliphant
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?
Yes. -n
participants (2)
-
Nathaniel Smith
-
Travis Oliphant