Repository navigation
Conversation
|
I'm sorry, but I'm very much against emitting the warning whenever units is imported. I suspect that hardly anyone is using this unit (I have to admit that I have never heard of it before this issue came up), while the warning will bite everyone. Getting rid of it without a deprecation seems less painful than the global warning. I had an idea at the time of the discussion in #4918, but never finished it up, will try and dig up the memories and figure out what it was and why it never worked. |
|
The underlying implication is that it won't be easy to deprecate prefix of, say, solarmass, as well. Perhaps, we can approach this another way. Instead of issuing deprecation warning, we can remove it right away as you said, but also keep the old version in a new module like |
|
I think this is indeed not a good idea, and I'll close this now as I think we should not have the discussion here, but rather in a place where we will still find it --> #5793 (which I turned the project note into and where I also comment on a possible solution). |
Here is an idea for deprecating
emu, as discussed in #4918. With this change, the warning will be emitted on import:This might not be a good idea, since we turn all deprecation warnings into exceptions in our tests. Hence, that is why I skipped CI in the commit, as I am pretty sure things will fail spectacularly.
I looked at
units/core.pyand could not find an easy way to only emit warning whenu.emuis called. I tried adding a new keyword calleddeprecated_aliasesindef_unit()but that turned complicated really fast, as I had to propagate that new keyword to__init__and__call__in several different places. Not sure if it is worth the while to add so many LOCs just to deprecate a unit.Anyway, if nothing else, this PR serves as a reminder and a place for discussions until a better one supersedes it. c/c @mhvk , @bsipocz
TODO (if we decide to proceed):