Personally, I would find __call__ confusing in this context. I rather use a more descriptive method.

@mdboom - well, travis shows that I did not do the parsing correctly: now, dex, dB, and mag are no longer interpreted as units if there is anything more than just their name in the string (i.e., u.Unit("mag") works, but not u.Unit("mag ")).

@pllim - the explicit method does already exist (u.DecibelUnit('mW')). I just seemed nice to be able to short-circuit this with u.dB(u.mW) -- but this is not a big deal.

@mdboom - I think I fixed the regex such that a function name will be interpreted as a unit if not followed by a parenthesis. Hence,

In [2]: u.Unit('dB / m')
Out[2]: Unit("dB / m")

In [3]: u.Unit('dB(mW)')
Out[3]: DecibelUnit('mW')

In [4]: u.Unit('dB (mW)')
Out[4]: DecibelUnit('mW')

The regex fix looks fine. Can you add a test with dB (mW) in it?

Personally, I like the suggestion of making dB(mW) work. @pllim: Can you explain your confusion? Seems non-ambiguous to me.

@mhvk , @mdboom , if it's clear to everyone else, then you can ignore my comment.

Hmm, adding tests as always is useful: it seems as written, any function can only take a single unit or a product of units in parentheses. This can be seen in master using sqrt: u.Unit('sqrt(m s)') does not work, 'sqrt((m s))' does work, 'sqrt((m/s))' does not work. @mdboom - would you have any suggestions?

On the callable magnitudes, etc., this is quite trivial to implement -- see proof of concept in #3618. But also brought to the fore some problems -- see main PR #1894.

Mostly for my own sake: to do here is to either disallow mag, dB',dex` in FITS, VOTable, OGIP, or make them work to the extend the standard allows (thus solving #3822).

@mdboom - I now rebased the parser and it seems to work fine for Generic (I added more tests as well).

For FITS and VOUnit, I've been blunt for now, and simply ensured that any function unit raises ValueError. As I'll need to read up on exactly how FITS and VOUnit support log, which will need a bit more time, I'd rather postpone that to #3822, so that we can be sure that the generic parsing is in for 1.1.

p.s. I quickly looked at the documentation, to see whether I should make changes, and I think with just this PR it is probably best to leave it as is. But if one also includes the callable units (#3618), the use of normal or function units becomes quite automatic and it would be logical to start omitting the whole DexUnit stuff in the documentation. instead, function units should just represent themselves as Unit("dex(cm / s2)"), and be created with that call or with u.dex(u.cm/u.s**2). The added advantage would be that we can change the API more easily...

I concur about putting off #3822. It's not a huge priority, as I don't think many other tools use functional units in those formats either.

I also think removing the DexUnit stuff from the documentation in favor of the more natural callable functions is a good idea.

Am closing this as it is part of #3618 (which also introduces the callable u.mag, etc.) and they would seem easiest reviewed as a package.