Love this idea!

Yes, this would be awesome! This would only work for the three argument version of where -- the one argument version isn't really ufunc like. So we can keep the public API unchanged, and don't need to support the confusing where(... where=...) unless we really want to :).

I believe that they are possible. However, would it be possible to make the one-argument version work with this? Or would the three-argument version defer to this?

I'd be willing to work up a PR if we can decide on a new home for this ufunc so we support the one-argument where.

@hameerabbasi - I think the idea would be that np.where calls the ufunc for its three-argument form (and for types of argument for which the ufunc works). For the one-argument form, no change would be made (since that behaviour cannot be captured by a ufunc).

Questions to all: what should be the name of the ufunc? We already have np.select. Harking to c, perhaps np.conditional(condition, a, b). Or, more fortran-ish, np.merge(a, b, condition)? Or should it be a private function that only gets called by np.where?

p.s. On dealing with void and string: that is a bit trickier, as it needs passing on lengths, etc. Possibly it is best to just start with the regular dtypes...

Questions to all: what should be the name of the ufunc? We already have np.select. Harking to c, perhaps np.conditional(condition, a, b). Or, more fortran-ish, np.merge(a, b, condition)? Or should it be a private function that only gets called by np.where?

In the issue I opened (before opening this one), I suggested if, but it's a Python keyword so not optimal. ternary would also work since it mimics the ternary operator. ifx from LaTeX would make sense too.

p.s. On dealing with void and string: that is a bit trickier, as it needs passing on lengths, etc. Possibly it is best to just start with the regular dtypes...

Use np.promote_types? Doesn't work for all cases though.

>>> np.promote_types('S8', 'S11')
dtype('S11')
>>> dt1 = np.dtype([('f1', np.int16), ('f2', np.float32)])
>>> dt2 = np.dtype([('f5', np.int16), ('f6', np.float32)])
>>> np.promote_types(dt1, dt2)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: invalid type promotion
>>> np.promote_types(dt1, dt1)
dtype([('f1', '<i2'), ('f2', '<f4')])

I don't like ternary as that's just the number of arguments, and one could think of other ufuncs with three arguments (e.g., the fused multiply and add discussed on the mailing list).

I also had another idea. I know numpy doesn't follow this too strictly, but how about if_ similar to operator.and_ et al.

I'm +1 on the name np.conditional. If someone can point me to similar ufunc implementations I'll try my hand at this one.

The casting would, I think, be fairly similar to addition (except that of course the boolean does not influence the outcome). The regular ufuncs are all defined in core/src/umath/, in particular loops.c.src; you may want to look at recent additions; e.g., #8774. Though if you haven't done a ufunc before, it might make sense to start without the scripting/looping in a .src file, and just follow the tutorial for writing a ufunc: https://docs.scipy.org/doc/numpy/user/c-info.ufunc-tutorial.html (I found this fairly helpful).

Regarding naming, I think np.where.ufunc is possibly the simplest place to put the actual ufunc object dispatched to by the special-casing of one-argument in np.where. Only users implementing __array_ufunc__ need to know where it is, and they'd find it organically while writing tests for the ufuncs they care about.