Should Imperial units be imported by default? - #1073

I can't think of a valid reason to have imperial units available by default for science. Though does it mean that e.g. u.inch won't be available?

It would mean u.inch wouldn't be available until doing from astropy.units import imperial. However, we could of course include inch as a one-off at the top-level if it's useful to have.

+1 for not including imperial units by default.

👍 to this, but can you add a prominent explanation how to bring them in somewhere close to the top of the units documentation page?

I totally agree this isn't usually useful for science, but occasionally one wants to do these conversions, and I have a feeling most users wouldn't realize this is here without having it prominently pointed out.

I wonder whether we want to have to require the user to import imperial, or whether we want a function/method-based way of doing it, e.g.

u.enable('imperial')

otherwise it's not clear to the user that importing a module will add new attributes to u.

+1 on some function-based approach. I saw the from astropy.units import imperial and immediately wondered "OK, so how do use the imperial units now?". Or might this be a ConfigurationItem?

I would say -1 to ConfigurationItem, because people might then write code that will work on one machine but not another depending on the local settings.

If we do take the u.enable approach, I would say that we also refactor all of the modules that define units so that everything happens inside a function -- i.e. importing doesn't define units. Maybe importing just causes it to register itself in the table that u.enable would use to enable units. Otherwise, we'll have MTOWTDI.

Also -- as suggested elsewhere, we should probably rename this from imperial or separate out the truly imperial from other units. Might as well do this as part of this PR.

I think the ultimate solution to this is probably to have a list of namespaces that are searched for things -- that will make it easier to add and later remove categories of units. I don't know if that needs to hold up this PR, though, which I think is a step forward in any case.

@eteq: In the part of the units documentation where the defined units are listed, it now includes an explanation about the fact that the imperial units are not included by default and how to get them. Is that sufficient? It seems like the right place to include this information. I'll also add this to some of the basic examples, which will put it front-and-center.

Yep, it seems fine to me other than the minor suggestion above.

There's also one test that is now failing. I think you just need to add the radioactivity units to the list in test_equivalent_units2, and perhaps a from from ... import units.imperial in that function just to make sure the imperials have been imported.

This does raise a minor concern that now the tests are somewhat non-deterministic, given that an import changes the package's state (order of tests is not necessarily guaranteed, I believe). Not a big deal to me, but perhaps worth noting at the top of the test file or something in case someone else gets tripped up by it.

I think I'm just going to put this off as it is now and rethink this in the context of how we want to handle optional namespaces of units in general.

Closing in favor of #1268.