[Numpy-discussion] Managing Python with NumPy and many external libraries on multiple Windows machines

Charles R Harris charlesr.harris@gmail....
Mon Apr 27 19:56:45 CDT 2009


On Mon, Apr 27, 2009 at 5:40 PM, Robert Kern <robert.kern@gmail.com> wrote:

> On Mon, Apr 27, 2009 at 18:36, Wes McKinney <wesmckinn@gmail.com> wrote:
> > On Mon, Apr 27, 2009 at 5:59 PM, Charles R Harris
> > <charlesr.harris@gmail.com> wrote:
> >>
> >> On Mon, Apr 27, 2009 at 3:05 PM, Wes McKinney <wesmckinn@gmail.com>
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am wondering if anyone can offer some suggestions on this problem.
> Over
> >>> the last year or so I have been building a number of libraries on top
> of
> >>> NumPy + SciPy + matplotlib and other libraries which are being used for
> >>> investigative research for my company's problem domain in place of,
> say,
> >>> Matlab and R (which are more "ready out of the box" systems). I have
> >>> approximately 20 users, all of whom are running Windows on a very
> >>> Microsoft-centric network with databases, etc. Has anyone had any luck
> >>> managing a standardized Python environment on lots of Windows machines
> with
> >>> a large number of 3rd-party Python libraries? Upgrading packages right
> now
> >>> involves getting 20 people to click through an .exe installer, which is
> >>> hardly a good solution. For example, I was recently forced to upgrade
> >>> everyone's NumPy to 1.3 after I discovered that a DLL I had built
> against
> >>> 1.3 was incompatible with 1.2.x.
> >>
> >> Out of curiosity, what was the nature of the incompatibility?
> >>
> >> Chuck
> >
> > A Cython DLL using the NumPy include and buffer interface (which worked
> fine
> > in 1.2.x, too) caused a hard crash on import, I wasn't able to diagnose
> > further.
>
> We have also encountered a number of segfaults upon import_array() on
> multiple platforms due to an extension module being built against
> numpy 1.3 but being imported after numpy 1.2.
>

Hmm... OK, I think that is because of the endianess function added to the
API. It is called during module load and since it isn't there for 1.2,
crash. There is also a check for the API version that should have raised an
error, but evidently not. I think the endianess check should probably be
moved to testing and not be done during the load. Or it can simply be
removed from the interface and/or be implemented inline. I don't think
having it in the interface is that important.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20090427/1b5d5985/attachment.html 


More information about the Numpy-discussion mailing list