[yt-dev] na => np in 3.0 and 2.x
Matthew Turk
matthewturk at gmail.com
Fri Aug 31 04:10:26 PDT 2012
Hi Nathan,
The question is if we should be merging to stable before applying the
na/np transformation. Additionally, as noted in the previous email,
we'll retain importing "na" in yt.mods for the indefinite future.
-Matt
On Fri, Aug 31, 2012 at 7:08 AM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> Strongly -1 on merging to stable as it will break user scripts. I know I'll
> have to update mine wherever I use the numpy imported along with yt.mods.
>
> -Nathan
>
>
> On 8/31/12 7:06 PM, Matthew Turk wrote:
>>
>> Hi all,
>>
>> Okay, looks like everybody's pretty much in favor. Anthony, would it
>> be possible to run the script on the tip of the 2.x repository and
>> issue a PR for that? And, do we want to merge to stable so that any
>> big bug fixes get applied there before doing so?
>>
>> -Matt
>>
>> On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>>>
>>> Nearly everyone who has replied so far is on board with the third
>>> option, which is to apply the same change to both. Anthony and Kacper
>>> also had a discussion in the PR about the cosmology routines, which
>>> seem to be (!!!) non-functional in some particular configurations of
>>> the universe. I'll suggest that we wait until Wednesday, and if
>>> nobody objects by then, we accept this PR and then also a similar one
>>> for the dev branch. I'd prefer we not apply these changes to the
>>> stable branch at this time.
>>>
>>> In IRC, Martin Geisler also pointed me at these StackOverflow
>>> questions which address merges and workflows like this:
>>>
>>> http://stackoverflow.com/a/9533927/110204
>>> http://stackoverflow.com/a/9500764/110204
>>>
>>> In short, by applying to both, we're going to be okay. :)
>>>
>>> -Matt
>>>
>>> On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz at gmail.com>
>>> wrote:
>>>>
>>>> Hello All,
>>>>
>>>> Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance
>>>> headache if you don't have to). I originally did this in the 3.0 fork
>>>> just
>>>> because
>>>> I thought it was more of a sandbox than the 2.x series. I am also +0 on
>>>> #1,
>>>> if that is what is best.
>>>>
>>>> Be Well
>>>> Anthony
>>>>
>>>>
>>>> On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik
>>>> <xarthisius.kk at gmail.com>
>>>> wrote:
>>>>>
>>>>> On 27.08.2012 16:08, Matthew Turk wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Hi,
>>>>> there's a way to minimize the disruption on any outstanding forks,
>>>>> namely to automate the process. If we use the same "tool" on both main
>>>>> repo and the fork, the difference should be close to none.
>>>>> In this case something along the lines:
>>>>>
>>>>> find . -name "*.py" \
>>>>> -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \
>>>>> -e "s/numpy as na/numpy as np/g" -i {} \;
>>>>>
>>>>> should do the trick. I haven't check yet if that reproduces Anthony's
>>>>> PR
>>>>> so use it carefully ;)
>>>>> Cheers,
>>>>> Kacper
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
More information about the yt-dev
mailing list