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

[Sam Skillman]

1) +0
2) -1
3) +1

Rip the bandaid.

On Mon, Aug 27, 2012 at 8:25 AM, John ZuHone <jzuhone at gmail.com> wrote:

> 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
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120827/66d95e7c/attachment.html>