The second aspect of this that would be nice to address:

As written, this PR will always issue a warning. Really, we only want the warning if units on one side of the operator are not specified and assumed dimensionless. If units are actually provided on both sides of the operator, it seems sensible to still raise the UnitOperationError and not the warning.

Unfortunately I can't see a way to figure out if the units are intended (i.e. a unyt_array that was intentionally created as dimensionless) or the units are dimensionless simply because they weren't specified and were assumed, i.e. as in:

Edit: the only option that occurs to me here is a new unit, assumed_dimensionless, but that would be a major change, or an extra bit of metadata on Unit

Would a unyt maintainer be willing to help me understand why test_ufunc is failing in this PR? Otherwise the functionality in this PR is fairly complete.

Hey I’ll try to take a look at this soon. Sorry for the radio silence, it’s hard for me to focus on programming tasks these days...

Many thanks @ngoldbaum, and no worries at all. Grateful for any feedback

Hey @mkhorton, I can help you with this. Since there is a conflict and unyt's CI was migrated to a different system, I'd advise you rebase this branch if you still want to work on this PR. Sorry it's been a while !

Hi @neutrinoceros, thanks for the offer to help! Would be very happy to see this functionality added.

I've resolved the current merge conflict and this branch is now up to date.

Alright, seems like there are 3 failures, 2 of which are code-style-related. Can you run black + flake8 and fix the warnings you get from the latter ? Then all that should be left is the ufunc issue.

Sorry the infrastructure isn't very well specified yet, it looks like you ran a different version of black that's conflicting with the latest. It'd be preferable to rebase and force push your branch now, to avoid tarnishing the history of files affected by cancelling changes. If you're not confortable with the process I can do it for you, just let me know.

Ok, I rebased, by all means make changes directly to my fork if preferred. I don't mind installing a specific version of black if necessary too.

We can always squash and rebase later to minimise disrupting your workflow. In the mean time I've pushed a single commit to fix the formatting issue. It is getting late in my timezone, I'll have a deeper look at the actual content tomorrow and hopefully we can move forward with this ufunc issue. Thank you so much for your patience.

@mkhorton Looks like both of your latest commits broke some tests, can you revert back to the last working state ?
should be as simple as

git reset --hard HEAD~2
git push --force

So I must say I do not disapprove of the idea, but I have mixed feelings about the current implementation. I'm thinking that Python has a builtin mechanism to change warnings into errors (see https://docs.python.org/3/using/cmdline.html#cmdoption-w), so maybe it's worth considering an alternative implementation where we always raise warnings instead of errors for invalid operations, and so developers of projects that consume the unyt library can choose when they want to turn the -Werror flag on in their CI (note that pytest, ipython and other CI relevant interpreters have support for -W and pass it down to python). In my opinion this alternative is worth considering, but it needs further discussion.
@ngoldbaum @jzuhone @matthewturk please weigh in.

Thanks @neutrinoceros, I was unaware of this functionality, I would also be in favour of this alternative since it's officially-supported by Python but will have to do some reading. Despite writing Python for quite a while, I feel like I'm still learning a lot :-)

I would also be grateful for any additional comments from other maintainers if anyone has thoughts on this functionality, especially if anyone has strong objections.