Sebastian Berg

Making the abstract and PyFloat do the same thing probably makes sense, but the fact that it doesn't work here seems like a bug somewhere that I (or we) need...

Ah, that makes sense (if I am getting the right picture). We are getting the abstract version as a result. In other paths that is OK because we only need...

Yeah, I suppose it probably isn't a concern in practice, so the choice we have may be the pragmatic one, even if it is slightly weird/reversed if we use it...

> I suppose we should add it to PyArray_CommonDType unless that's too big and we'd rather have it localized? Yeah, I am not sure I want that function to ensure...

> It doesn't seem we initiate the PyFloat with NPY_DT_ABSTRACT, though we do it for AbstractDType. Hmmmmmmm, we had some reason for changing that. FWIW, it's probably fine then, we...

> We can just pass the float_common_dtype pointer right? Basically except that may return one of the `Py*DType` which would be wrong when we need to return one of the...

Pushed a small fixup mostly for additional error checks. I also broadened it up to all integer inputs (including int32, etc.). NumPy promotion should go to float64 for integers of...

> What will happen with complex input? Nothing, the promoter will never be called and even if it was, it wouldn't do anything. There are no complex loops anyway.

> Yes, likely some downstream bug Well, this is should be in the SIMD code path I think, but let's see. So it may or may not be the system...

@charris I don't think this is a real world issue, so you don't have to prioritize this for 2.2.5. To me it looks like some auto tool finding minor (basically...