ENH: improve error messages when add_field receives a malformed function argument

[neutrinoceros]

PR Summary

This makes life easier for clumsy users like myself who can never remember what argument goes first in a derived field function, so you get a clear error message instead of whatever happens when the malformed function gets called with reversed arguments. Incidentally adds support and tests for passing arbitrary callables as the function argument.

edit: I also reworked the way units="auto" works to make the dimensions argument optional even in that case. This is an opinionated change but I think it's reasonable as long as a warning is displayed when needed.

[neutrinoceros]

switched to draft because I realised that in my tests, I was adding fields that are inaccessible since I provided neither dimensions or units. I feel like the add_field method should raise an error instead of positioning it to actual data access time, but this will probably require some minor changes in the API, so I need to think about it.

[neutrinoceros]

Failures are unrelated and likely to be caused by pypa/pip#11116

[matthewturk]

edit: I also reworked the way units="auto" works to make the dimensions argument optional even in that case. This is an opinionated change but I think it's reasonable as long as a warning is displayed when needed.

I have found the units="auto" functionality to be confusing; my reading of this was always that it would identify whatever units came out, and allow those. It wouldn't precisely allow for silent failures, but it would stop validating the units, and instead be descriptive rather than prescriptive. Is that the new behavior?

[neutrinoceros]

Kinda. I'm not sure what you mean by "descriptive rather than prescriptive", and I'm not sure that I can say that it doesn't allow for silent failures: with the new behaviour, validation can be omitted completely (but you do get a warning)

[matthewturk]

I guess what I mean is, validation will fail, but you still get the units that come out of the field. i.e., it still tracks, but does not do validation against a priori values

[neutrinoceros]

Yes I think that's correct.

[matthewturk]

I'm generally OK with this. I have a question though: without passing judgment on them, can you estimate how many people might have their derived fields broken by this? 0, a few, or lots?

[neutrinoceros]

I would naively assume none to a few, but we may want to be slightly more cautious and raise a warning instead of an error for a while (and explicitly state that it'll be an error in the future). Your call :)

[matthewturk]

I don't think that is necessary.