[Numpy-discussion] Created NumPy 1.7.x branch

[Charles R Harris]

On Sat, Jun 23, 2012 at 3:23 AM, Thouis (Ray) Jones <thouis at gmail.com>wrote:

> On Sat, Jun 23, 2012 at 5:14 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> > What has been done in the past is that an intent to fork is announced
> some
> > two weeks in advance so that people can weigh in on what needs to be done
> > before the fork. The immediate fork was a bit hasty. Likewise, when I
> > suggested going to the github issue tracking, I opened a discussion on
> > needed tags, but voila, there it was with an incomplete set and no
> > discussion. That to seemed hasty.
>
> I don't have a particular dog in this fight, but it seems like neither
> creating the fork nor turning on issues are worth disagreeing to much
> about.  There's going to be a 1.7 fork sometime soon, and whether it
> gets created now or after discussion seems mostly academic.  Even if
> there were changes that needed to go into both branches, git makes
> that straightforward.  Likewise github issues.  Turning them on has
> minimal cost, especially given that pull requests already go through
> github, and gives another route for bug reporting and a way to
> experiment with issues to inform the discussion.
>
> > [...]
> > Most folks aren't going to transition from MATLAB or IDL. Engineers tend
> to
> > stick with the tools they learned in school, they aren't interested in
> the
> > tool itself as long as they can get their job done. And getting the job
> done
> > is what they are paid for. That said, I doubt they would have much
> problem
> > making the adjustment if they were inclined to switch tools.
> > [...]
>
> My own experience is the opposite.  Most programmers/engineers I've
> worked with are happy to transition away from Matlab, but part of why
> they're willing to is that it's not that difficult to retarget Matlab
> knowledge onto numpy/scipy/matplotlib knowledge.  Making that
> transition as easy as possible (as I think matplotlib does
> particularly well) is a good goal.  I agree that getting the job done
> is what they're paid for, but python/numpy/scipy/matplotlib allow them
> to get that job done much faster and more easily.
>

Haven't seen that myself. When engineers' time is paid for out of contracts
and the work is on a schedule, they generally don't have the time to chase
after new things unless the payoff is substantial. Matlab is also widely
used for rapid prototyping of control systems with the models then
translated to run on the actual hardware. Not to mention that device makers
often provide Simulink models of their hardware.That sort of thing is not
available in Python. I agree that there are many places that Python could
work better, but the old rule of thumb is that the effective savings need
to be on the order of a factor of ten to drive a new technology takeover of
a widespread existing technology.  Of course, that doesn't hold for new
markets.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120623/01ce8168/attachment.html>