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... 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