Decide on the UFunc Inner loop signature and setup/teardown API

[seberg]

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).

[seberg]

Long discussion on this topic: numpy#12518

[seberg]

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]

Just so we don't forget: xref numpy#9963 where np.remainder should be able to take a keyword argument to specify the method: C99, modulus, or rem (without bikeshedding the names right now)

[seberg]

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.