Maybe use not X instead of X is False ?

Will do, is there any technical difference between X is False and not X that I am not aware of?

They are not the same. In Python is checks to see if the two names point to the same object ("object identity"). So although using is works fine here, it wouldn't in other cases because it requires the LHS to be exactly the object False. Using not X will coerce X to a bool, which is in general what you want.

a = False

a is False
Out[2]: True

b = 0 

b is False
Out[4]: False

not b
Out[5]: True

I would also argue that is False or is True isn't really idiomatic.

Thank you for the explaination.

Someone else used a function that might be good here, result_type. So maybe something like

dt = np.result_type(a, 0.0)

I agree that before a = a.astype('float64') using dt = np.result_type(a, 0.0) would be appropriate. However, as @jaimefrio mentioned before astype requires an intermediate array for the conversion. So I was thinking of using a = np.multiply(1.0, a).
So the fix would look like the following:

if issubclass(a.dtype.type, (integer, bool)):
    a = np.multiply(1.0, a)

Otherwise I could do it the alternative way using result_type, then the fix would look like this:

if issubclass(a.dtype.type, (integer, bool)):
    dt = np.result_type(a, 0.0)
    a = a.astype(dt)

Don't use a multiplication for this.

I think @jaimefrio was suggesting that you select the dtype via dt = np.result_dtype(a, 0.0) and then later on in the function, specify that dtype in the ufunc call. So down below it has something like avg = np.multiply(a, wtg).sum(axis)/scl the suggestion is to change this to avg = np.multiply(a, wtg, dtype=dt).sum(axis)/scl and, of course, whatever other changes are needed to ensure the dtype handling is still or becomes correct.

Doing it this way means that you don't ever have to have a full copy of a around since the ufunc machinery will convert a for you using a reasonably sized buffer.

Thinking somemore, this is probably a good use cars for einsum. It can do the necessary sum product without any temporaries. The only possible drawback is that we would then miss out on the pair wise summation that np.add does these days. Seems like a good trade off to me. The fastest implementation for the 1d case is probably via vdot, too FWIW.