Repository navigation
Decide on the UFunc Inner loop signature and setup/teardown API #12
Description
Note that we can iterate this later on, since UFuncImpl or UFuncLoop will be its own object, and we can create new subclasses with slightly different behaviour.
We could also move most logic into UFuncImpl.__call__(), keeping everything even more open. Although there are arguments for providing get_innerloop_function(...) (which could double as setup). The Advantage here would be that it allows inner loop specialization for strided, or scalar values. Additionally, with a somewhat limited API, UFuncImpls adhering to it, could for example allow chaining more easily. (Side note: CastingImpls must provide this, but the public API could be very limited initially).
The inner loop itself (IMO) must get a new int return value to signal stopping of the iteration. Everything else could probably be set up by using the existing void * argument (e.g. passing in dtypes can happen there, or allocations be stored on something passed in to it).
Activity
seberg commentedon Nov 20, 2019
Long discussion on this topic: numpy#12518
seberg commentedon Nov 20, 2019
One more important point (mentioned in the above thread): Whether or not the GIL should be dropped, is something that the setup function should likely be able to decide (or at least enforce).
If it is dropped, we may want to provide a way to to get access to the GIL state though, since the inner loop might want to grab it (cleanly)!
mattip commentedon Dec 5, 2019
Just so we don't forget: xref numpy#9963 where
np.remaindershould be able to take a keyword argument to specify the method:C99,modulus, orrem(without bikeshedding the names right now)seberg commentedon Dec 5, 2019
Yes, good point. Although, I think kwargs are a job for a step before the inner-loop. I think it would be OK if its slightly inconvenient and has to be passed in using the
void *data.Add 64 bit Windows builds [wheel build]