[yt-dev] na => np in 3.0 and 2.x

[Matthew Turk]

Hi all,

On Friday, Anthony submitted a PR to the yt-3.0 branch:

https://bitbucket.org/yt_analysis/yt-3.0/pull-request/4/na-is-dead-long-live-np

This PR is pretty invasive, and done by regular expressions.
Basically, for a long time we've been sticking with a convention I
started using about ... six years ago ... when NumArray was the
dominant array language.  (Or when I was still too removed from
Python's scientific community to see otherwise.)  The array library
was shortened to 'na'.  Almost immediately after, NumPy took over and
while we switched to NumPy we never updated the shorthand in the
Python code to 'np'.  (The Cython code always uses 'np')  Most python
tutorials use np instead of numpy, and I'd like to encourage best
practices in yt as well as suggest we try to fit into the broader
ecosystem of packages.

Anyway, this is kind of a bandaid that needs to be ripped off at some
point, and I think it's appropriate to discuss now.  I see three
options, which basically break down on levels of disruption and ease
of the dual-lines of development we currently have.

1) Put this PR (which applies only to 3.0) on hold.  This way, merging
from 2.x to 3.0 can proceed easily, and the disruption is completely
pushed off for a bit.
2) Accept the PR.  This increases the burden on me for merging
considerably, and it would fall on me.  Any file where both a numpy
line and another line are changed would throw a conflict that I'd have
to manually resolve.  But, because it would just be in the 3.0 line,
disruption would be kept to a minimum.
3) Accept the PR *but* also mandate that we apply it to the main
repository's development branch (2.x).  This would be the most
disruptive, but it would also keep merging difficulty to a minimum.
As a compatibility layer, we'll keep "na" in the yt.mods namespace,
which means my_plugins.py files would still work, as would existing
scripts.

Because this could be disruptive for any major, outstanding forks, I
also think it needs to be discussed here.  (I'm actually kind of -1 on
big discussions happening in pull requests.)  My vote is for #3.  I'd
rather get this over with, since we all know it probably ought to
happen at some point in the future.

What do people think -- of the three options, which is your favorite,
and do you have strong feelings against any one option?

-Matt