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

[John ZuHone]

My vote is #3, since otherwise we'll be faced with the same trilemma later if we don't.

John ZuHone
Laboratory for High-Energy Astrophysics
NASA/Goddard Space Flight Center
8800 Greenbelt Rd., Code 662
Greenbelt, MD 20771
(w) 301-286-2531
(m) 773-758-0172
jzuhone at gmail.com
john.zuhone at nasa.gov

On Aug 27, 2012, at 10:08 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org