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

[Britton Smith]

+1 on #3.

On Mon, Aug 27, 2012 at 10:27 AM, Sam Skillman <samskillman at gmail.com>wrote:

> 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
>>
>
>
> _______________________________________________
> 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/b4f0d410/attachment.html>