tools/win32build is used to build the so-called superpack installers, which
we don't build anymore AFAIK
tools/numpy-macosx-installer is used to build the .dmg for numpy (also not
used anymore AFAIK).
On Sat, Feb 25, 2017 at 3:21 PM, Charles R Harris wrote:
> Hi All,
>
> While looking through t
Indeed. I wrongly assumed that since gholke's wheels did not crash, they
did not run into that issue.
That sounds like an ABI issue, since I suspect intel math library supports
C99 complex numbers. I will add info on that issue then,
David
On Mon, Jan 23, 2017 at 11:46 AM, Evgeni Bur
.
I am a bit suspicious about the whole thing as neither conda's or gholke's
wheel crashed. Has anybody else encountered this ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
binary compatibility with centos 5.X
and above, though I am not sure about the impact on speed.
It has been quite some time already that building numpy/scipy with gcc 4.1
causes troubles with errors and even crashes anyway, so you definitely want
to use a more recent compiler in any case.
David
+1 from me.
If we really need some distribution on top of github/pypi, note that
bintray (https://bintray.com/) is free for OSS projects, and is a much
better experience than sourceforge.
David
On Sun, Oct 2, 2016 at 12:02 AM, Charles R Harris wrote:
> Hi All,
>
> Ralf has suggested
y (you can access numpy arrays directly as C arrays), very python like
syntax and amazing performance.
Good luck,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Joseph Fox-Rabinovitz
gmail.com> writes:
>
> On Wed, Jul 6, 2016 at 2:57 PM, Eric
Firing hawaii.edu> wrote:
> > On 2016/07/06 8:25 AM, Benjamin Root
wrote:
> >>
> >> I wouldn't have the keyword be
"where", as that collides with the notion
> >> of "where" elsewhere in numpy.
> >
> >
> > Agre
Which are the best ways to turn a JSON object into a CSV or Pandas data frame
table?
Looking forward to hearing from you.
Regards.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy
o in scipy, but it was a PITA to maintain. Contrary
to blas/lapack, fft does not have a standard API, hence exposing a
consistent API in python, including data layout involved quite a bit of
work.
It is better to expose those through 3rd party APIs.
David
> Sturla
>
>
problem dumping the array.
I am using NumPy v1.9.3
Any ideas on why this might be happening?
Thank you,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
ebra.
>
I would not worry too much about this: at worst, this gives us back the
situation where we were w/ so-called superpack, which have been successful
in the past to spread numpy use on windows.
My main worry is whether this locks us into ATLAS for a long time because
of package dependin
gt;> well as just having a talk on Numpy at a PyData conference. In general
>> there are too few (if any) talks on Numpy and other core libraries at
>> PyData and Scipy confs I think.
>>
>
> +1.
>
> It would
what's used by distutils to build C extensions.
This is only valid on Unix/cygwin, if you are on windows, the process is
completely different.
David
>
> Thanks for your help,
>
> Christian
>
>
>
> This email and any attachments are intended solely for the use of the
&
uld) do, such as writing the expected
metadata in site-packages (PEP 376). Currently, conda does not recognize
packages installed by pip (because it does not implement PEP 376 and co),
so if you do a "pip install ." of a package, it will likely break existing
package if present.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jan 11, 2016 at 6:25 PM, Chris Barker wrote:
> On Fri, Jan 8, 2016 at 7:13 PM, Nathaniel Smith wrote:
>
>> > that this would potentially be able to let packages like numpy serve
>> their
>> > linux
>> > users better without risking too much junk being uploaded to PyPI.
>>
>> That will ne
inux systems are now transitioning to C++11 which is binary
> incompatible in parts to the old standard. There a lot of testing is
> necessary to check if we are affected.
> How does Anaconda deal with C++11?
>
For canopy packages, we use the RH devtoolset w/ gcc 4.8.X, and staticall
ubt are directly
> used by the packages.
>
It is also a common problem when building packages without using a "clean"
build environment, as it is too easy to pick up dependencies accidentally,
especially for autotools-based packages (unless one uses pbuilder or
similar tools).
David
how many people are running 32 bit Python on Windows these
> days??
>
I don't claim we are representative of the whole community, but as far as
canopy is concerned, it is still a significant platform. That's the only 32
bit platform we still support (both linu
that may has
been fixed since then.
David
> Anne
>
> On Fri, Dec 11, 2015, 16:46 Charles R Harris
> wrote:
>
>> On Fri, Dec 11, 2015 at 6:25 AM, Thomas Baruchel
>> wrote:
>>
>>> From time to time it is asked on forums how to extend precision of
>>>
andint and np.random.rand
> could use an extra 'dtype' keyword. It didn't look easy to implement though.
>
> Allan
>
> On 12/06/2015 04:55 PM, DAVID SAROFF (RIT Student) wrote:
>
>> Matthew,
>>
>> That looks right. I'm concluding that the .astype
10GBy files.
linearInputData = np.fromfile(dataFile, dtype = np.uint8, count = -1)
spectrumArray = linearInputData.reshape(nSpectra,sizeSpectrum)
On Sun, Dec 6, 2015 at 4:07 PM, Matthew Brett
wrote:
> Hi,
>
> On Sun, Dec 6, 2015 at 12:39 PM, DAVID SAROFF (RIT Student)
> wrote:
>
is a factor of two, 2**21 rather than 2**20, for the extent
of the first axis.
--
David P. Saroff
Rochester Institute of Technology
54 Lomb Memorial Dr, Rochester, NY 14623
david.sar...@mail.rit.edu | (434) 227-6242
___
NumPy-Discussion mailing list
NumPy
Thanks a lot for providing the example Sturla, that is exactly what we are
looking for!
On 4 December 2015 at 11:34, Sturla Molden wrote:
> On 03/12/15 22:07, David Verelst wrote:
>
> Can this workflow be incorporated into |setuptools|/|numpy.distutils|?
>> Something alo
On Fri, Dec 4, 2015 at 11:06 AM, Nathaniel Smith wrote:
> On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau
> wrote:
> > I would be in favour of dropping 3.3, but not 2.6 until it becomes too
> > cumbersome to support.
> >
> > As a data point, as of april, 2.6 was m
I would be in favour of dropping 3.3, but not 2.6 until it becomes too
cumbersome to support.
As a data point, as of april, 2.6 was more downloaded than all python 3.X
versions together when looking at pypi numbers:
https://caremad.io/2015/04/a-year-of-pypi-downloads/
David
On Thu, Dec 3, 2015
pywafo/blob/pipinstall/setup.py
[3] http://docs.scipy.org/doc/numpy/reference/distutils.html
Regards,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
f90wrap [1] extends the functionality of f2py, and can automatically
generate sensible wrappers for certain cases.
[1] https://github.com/jameskermode/f90wrap
On 15 July 2015 at 03:45, Sturla Molden wrote:
> Eric Firing wrote:
>
> > I'm curious: has anyone been looking into what it would take t
king into structured arrays. In case it is relevant: Are you
using certain 1.10? They are apparently a LOT slower than 1.9.3, an issue
which will be fixed in a future version.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
s. You will need a way to install things when
building a conda package in any case
David
> Is there any particular reason for not using it?
>
> On Tue, Oct 27, 2015 at 11:48 AM, James E.H. Turner
> wrote:
>
>> Apparently it is not well known that if you have a Python project
ds, but for us at Enthought,
windows 32 bits is in the same ballpark as OS X and Linux (64 bits) in
terms of proportion, windows 64 bits being significantly more popular.
Linux 32 bits and OS X 32 bits have been in the 1 % range each of our
downloads for a while (we recently stopped support for bo
On Thu, Oct 8, 2015 at 8:47 PM, Nathaniel Smith wrote:
> On Oct 8, 2015 06:30, "David Cournapeau" wrote:
> >
> [...]
> >
> > Separating the pure C code into static lib is the simple way of
> achieving the same goal. Essentially, you write:
&
On Tue, Oct 6, 2015 at 8:04 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 11:52 AM, David Cournapeau
> wrote:
> >
> >
> > On Tue, Oct 6, 2015 at 7:30 PM, Nathaniel Smith wrote:
> >>
> >> [splitting this off into a new thread]
> >>
&g
On Tue, Oct 6, 2015 at 7:30 PM, Nathaniel Smith wrote:
> [splitting this off into a new thread]
>
> On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau
> wrote:
> [...]
> > I also agree the current situation is not sustainable -- as we discussed
> > privately before, cyt
On Tue, Oct 6, 2015 at 6:18 PM, David Cournapeau wrote:
>
>
> On Tue, Oct 6, 2015 at 6:14 PM, Nathaniel Smith wrote:
>
>> On Tue, Oct 6, 2015 at 10:10 AM, David Cournapeau
>> wrote:
>> >
>> >
>> > On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smi
On Tue, Oct 6, 2015 at 6:14 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 10:10 AM, David Cournapeau
> wrote:
> >
> >
> > On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smith wrote:
> >>
> >> On Tue, Oct 6, 2015 at 10:00 AM, Antoine Pitrou
> >&
has worked
fairly well and has been used in at least scipy since the 1.4/1.5 days IIRC
(including windows).
David
>
> > And, of course, we would also benefit from the CBLAS functions (or any
> > kind of C wrappers around them) :-)
> > https://github.com/numpy/numpy/issues/63
On Tue, Oct 6, 2015 at 5:58 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 9:51 AM, David Cournapeau
> wrote:
> >
> > On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
> >>
> >> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
> >> wro
On Tue, Oct 6, 2015 at 5:51 PM, David Cournapeau wrote:
>
>
> On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
>
>> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
>> wrote:
>> > The npy_ functions in npymath were designed to be exported. Those would
&
On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
> wrote:
> > The npy_ functions in npymath were designed to be exported. Those would
> stay
> > that way.
>
> If we want to export these then I vote that we ei
On Tue, Oct 6, 2015 at 12:07 PM, Antoine Pitrou wrote:
> On Tue, 6 Oct 2015 11:00:30 +0100
> David Cournapeau wrote:
> >
> > Assuming one of the rumour is related to some comments I made some time
> > (years ?) earlier, the context was the ability to hide exported sy
ommon functionalities (aka the
'core' library) into its own static library. The API would be considered
private to numpy (no stability guaranteed outside numpy), and every
exported symbol from that library would be decorated appropriately to avoid
potential clashes (e.g. '_npy_i
cannot fully, nor do you
> have to, I will let it stand as is after this and let others take over
> from here (after this, probably whatever Chuck says is good). [1]
>
> More to the point of the actual members:
>
> So to say, I feel the council members have to try to be *directly
onsider along the way is separating numpy.multiarray
> and friends into an actual library plus a module. That way the new numpy
> api would be exposed in the library rather than by importing an array of
> pointers from the module.
>
Agreed.
This would help the cythonizing process a
iculable, concrete points
> of concern? Otherwise this just seems like idle, non-constructive
> speculation (at best).
>
There is ample history of such things happening in OSS history, so I think
that's a fair concern, even if that has not happened for numpy yet.
David
__
a python with all libraries static linked. Here is the
environment:
iOS 8.0+
Python 3.4
PyQt 5.5
Qt 5.5
pyqtdeploy
Any help getting NumPy compiled into the iOS app?
Thank you,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https
e sources for a given tag is
confusing.
David
>
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
_
On Tue, Sep 1, 2015 at 8:16 AM, Nathaniel Smith wrote:
> On Sun, Aug 30, 2015 at 2:44 PM, David Cournapeau
> wrote:
> > Hi there,
> >
> > Reading Nathaniel summary from the numpy dev meeting, it looks like
> there is
> > a consensus on using cython in
e are < 60 methods in the table, and most of them should be fairly
straightforward to cythonize. At worse, we could just keep them as is
outside cython and just "export" them in cython.
Does that sound like an acceptable plan ?
If so, I will star
team to
improve this ? Or was that considered acceptable with current cython for
numpy. I am convinced cleanly separating the low level parts from the
python C API plumbing would be the single most important thing one could do
to make the codebase more amenable.
David
On Tue, Aug 25, 2015 at 9
On Wed, Aug 19, 2015 at 1:22 AM, Nathaniel Smith wrote:
> On Tue, Aug 18, 2015 at 4:15 PM, David Cournapeau
> wrote:
> > If everybody wants to remove bento, we should remove it.
>
> FWIW, I don't really have an opinion either way on bento versus
> distutils, I j
end ?
David
On Tue, Aug 18, 2015 at 9:07 PM, Charles R Harris wrote:
> Hi All,
> .
> I'm bringing up this topic again on account of the discussion at
> https://github.com/numpy/numpy/pull/6199. The proposal is to stop
> (trying) to support the Bento build system for Numpy
Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Thu, Aug 6, 2015 at 4:22 PM, David Cournapeau
>> wrote:
>>
>>> Sorry if that's obvious, but do you have Visual Studio 2010 installed ?
>>>
>>> On Th
Sorry if that's obvious, but do you have Visual Studio 2010 installed ?
On Thu, Aug 6, 2015 at 11:17 PM, Charles R Harris wrote:
> Anyone know how to fix this? I've run into it before and never got it
> figured out.
>
> [192.168.121.189:22] out: File
> "C:\Python34\lib\distutils\msvc9compiler.
In any case I've always been surprised that NumPy is distributed
> through SourceForge, which has been sketchy for years now. Could it
> simply be hosted on PyPI?
>
They don't accept arbitrary binaries like SF does, and some of our
installer formats can't be uploade
IMO, this really begs the question on whether we still want to use
sourceforge at all. At this point I just don't trust the service at all
anymore.
Could we use some resources (e.g. rackspace ?) to host those files ? Do we
know how much traffic they get so estimate the cost ?
David
On Thu
A is C-style and B fortran-style.
>
Does your implementation use BLAS, or is just a a wrapper around einsum ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
on how much it lets us simplify things, I guess. Would we get to
> remove all the no-export attributes on everything?
>
No, the whole point of the no-export is to support the separate compilation
use case.
David
> On Apr 3, 2015 8:01 PM, "Charles R Harris"
> wrote:
>
>
>
I concur on that: For the 350+ packages we support at Enthought, cmake has
been a higher pain point than any other build tool (that is including
custom ones). And we only support mainstream platforms.
But the real question for me is what does visual studio support mean ? Does
it really mean solution files ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
I'll be there as well, though I am still figuring out when exactly .
On Wed, Feb 18, 2015 at 1:07 AM, Nathaniel Smith wrote:
> Hi all,
>
> It looks like I'll be at PyCon this year. Anyone else? Any interest in
> organizing a numpy sprint?
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
>
Sebastian Berg sipsolutions.net> writes:
>
> Python has a mechanism both for getting an item and for setting an item.
> The latter will end up doing this (python already does this for us):
> x[:,d,:,d] = x[:,d,:,d] + 1
> so there is an item assignment going on (__setitem__ not __getitem__)
>
> -
copy?
Thanks,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
://github.com/numpy/numpy/blob/master/numpy/core/setup.py#L638
David
On Sat, Jan 31, 2015 at 9:53 PM, Sebastien Gouezel <
sebastien.goue...@univ-rennes1.fr> wrote:
> Dear all,
>
> I tried to use numpy (version 1.9.1, installed by `pip install numpy`)
> on cygwin64. I encount
Visual Studio C, but this give undefined symbols from 'libnpymath.a'
> like this:
>
This is not really supported. You should avoid mixing compilers when
building C extensions using numpy C API. Either all mingw, or all MSVC.
David
>
> npymath.lib(npy_math.o) : error LNK2
/ similar results.
Thanks for all the hard work,
David
On Sun, Dec 14, 2014 at 10:29 PM, Pauli Virtanen wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
>
> We have finished preparing the Scipy 0.14.1 release candidate 1.
> If no regressions turn
On Sun, Nov 30, 2014 at 5:45 PM, Charles R Harris wrote:
>
>
> On Sun, Nov 30, 2014 at 4:54 AM, David Cournapeau
> wrote:
>
>> Hi there,
>>
>> I remember having seen some numpy-aware gdb macros at some point, but
>> cannot find any reference. Does anyon
Hi there,
I remember having seen some numpy-aware gdb macros at some point, but
cannot find any reference. Does anyone know of any ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
oups, I missed it. Will use that one then.
On Wed, Nov 26, 2014 at 9:01 AM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 11/26/2014 09:44 AM, David Cournapeau wrote:
> > Hi,
> >
> > Would anybody mind if I create a label "newcomers" on GH,
Hi,
Would anybody mind if I create a label "newcomers" on GH, and start
labelling simple issues ?
This is in anticipation to the bloomberg lab event in London this WE. I
will try to give a hand to people interested in numpy/scipy,
David
___
On Tue, Nov 25, 2014 at 6:10 PM, Sturla Molden
wrote:
> David Cournapeau wrote:
> > Shall we consider > href="https://github.com/scipy/scipy/issues/4168";>
> https://github.com/scipy/scipy/issues/4168
> > to be a
> > blocker (the issue arises on scipy m
Shall we consider https://github.com/scipy/scipy/issues/4168 to be a
blocker (the issue arises on scipy master as well as 0.14.1) ?
On Sun, Nov 23, 2014 at 11:13 PM, Pauli Virtanen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
>
> We have finally finished preparing the S
on't see the issues with f2py
not being able to
I am starting to think I got on the wrong track regarding the original
issue I see with scipy 0.14.x on win 32 bits... I will create a separate
ticket for that.
David
___
NumPy-Discussion
y 1.8.1 always returned 16 bytes aligned arrays in this
case (unlikely to be a coincidence, as I try quite a few times with
different sizes).
>
> is the array aligned?
>
> On 18.11.2014 19:37, David Cournapeau wrote:
> > Additional point: it seems to always return aligned data on
Additional point: it seems to always return aligned data on 1.8.1 (same
platform/compiler/everything).
On Tue, Nov 18, 2014 at 6:35 PM, David Cournapeau
wrote:
> It is on windows 32 bits, but I would need to make this work for complex
> (pair of double) as well.
>
> Is this a bug
).
(the context is > 100 test failures on scipy 0.14.x on top of numpy 1.9.,
because f2py intent(inout) fails on work arrays created by zeros, this is a
windows-32 only failure).
David
On Tue, Nov 18, 2014 at 6:26 PM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 18.11.2014
Hi,
I have not followed closely the changes that happen in 1.9.1, but was
surprised by the following:
x = np.zeros(12, "d")
assert x.flags.aligned # fails
This is running numpy 1.9.1 built on windows with VS 2008. Is it expected
that zeros may return a non-aligned arra
gt; interface, rather than having us debate which fft library is 'best'.
>
I would agree if it were not already there, but removing it (like
Blas/Lapack) is out of the question for backward compatibility reason. Too
much code depends on it.
David
>
> On Tue, Oct 28, 2014 at
On Tue, Oct 28, 2014 at 3:06 PM, David Cournapeau
wrote:
> I
>
> On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith wrote:
>
>> On 28 Oct 2014 07:32, "Jerome Kieffer" wrote:
>> >
>> > On Tue, 28 Oct 2014 04:28:37 +
>> > Nathaniel Smi
t the Bluestein
transform to deal with prime/near-prime numbers on top of FFTS.
I did not look much, but it did not obviously support building on windows
as well ?
David
> -n
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy
thing missing from fftpack is the handling of transform sizes that
> are not products of 2,3,4,5.
>
Strickly speaking, it is handled, just not through an FFT (it goes back to
the brute force O(N**2)).
I made some experiments with the Bluestein tr
MKL, Accelerate, etc... all use a standard API
(BLAS/LAPACK), but for FFT, you need to reimplement pretty much the whole
thing. Unsurprisingly, this meant the code was not well maintained.
Wrapping non standard, non-BSD libraries makes much more sense in separate
libraries in general.
David
>
Not exactly: if you build numpy with mingw (as is the official binary), you
need to build everything that uses numpy C API with it.
On Sun, Oct 26, 2014 at 1:22 AM, Matthew Brett
wrote:
> On Sat, Oct 25, 2014 at 2:15 PM, Matthew Brett
> wrote:
> > On Fri, Oct 24, 2014 at 6:04 PM, Matthew Brett
ew dtype: numpy hardcodes that long double is the highest
precision floating point type, for example, and there were similar issues
regarding datetime handling. Does not matter for completely new types that
don't require interactions with others (categorical ?).
Would it help to prepare a set of
you can go, and
come back to this group with the result of your investigation.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
sage is not bogus, I would try import von_mises with a venv
containing numpy 1.5.1, then 1.6.0, etc... to detect when the change
happened.
David
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
>
On Sat, Aug 2, 2014 at 11:36 AM, Charles R Harris wrote:
>
>
>
> On Fri, Aug 1, 2014 at 8:22 PM, David Cournapeau
> wrote:
>
>>
>>
>>
>> On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>
On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris wrote:
>
>
>
> On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau
> wrote:
>
>> On my machine, if I use inspect instead of _inspect in
>> numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99
>&
e was bundled for).
David
On Sat, Aug 2, 2014 at 5:11 AM, David Cournapeau wrote:
>
>
>
> On Fri, Aug 1, 2014 at 11:23 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Aug 1, 2014 at 7:59 AM, Robert Kern
>> wro
they are
>> used if you feel compelled to. Please do not replace the current uses
>> of `_inspect` with `inspect`.
>>
>
> It is used in just one place. Is importing inspect so much slower than all
> the other imports we do?
>
Yes, please look at the thread I referred to. The custom inspect cut
imports by 30 %, I doubt the ratio is much different today.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
The docstring at the beginning of the module is still relevant AFAIK: it
was about decreasing import times. See
http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html
On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris wrote:
> Hi All,
>
> The _inspect.py function looks like a
On Sun, Jul 6, 2014 at 2:24 AM, Julian Taylor wrote:
> On 05.07.2014 19:11, David Cournapeau wrote:
> > On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor
> > mailto:jtaylor.deb...@googlemail.com>>
> > wrote:
> >
> > On 05.07.2014 18:40, David Cournap
On Sun, Jul 6, 2014 at 2:24 AM, Julian Taylor wrote:
> On 05.07.2014 19:11, David Cournapeau wrote:
> > On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor
> > mailto:jtaylor.deb...@googlemail.com>>
> > wrote:
> >
> > On 05.07.2014 18:40, David Cournap
On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor wrote:
> On 05.07.2014 18:40, David Cournapeau wrote:
> > The efforts are on average less demanding than this discussion. We are
> > talking about adding entries to a list in most cases...
> >
> > Also, while adding the opt
OS X + clang.
David
On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith wrote:
> On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau
> wrote:
> >
> > On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith wrote:
> >>
> >> Maybe bento will revive and take over the new pyth
On Sat, Jul 5, 2014 at 11:51 PM, Charles R Harris wrote:
>
>
>
> On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett
> wrote:
>
>> On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau
>> wrote:
>> >
>> >
>> >
>> > On Sat, Jul 5, 2014 at
On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith wrote:
> On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers
> wrote:
> >
> > On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith wrote:
> >>
> >> On 5 Jul 2014 09:23, "Ralf Gommers" wrote:
> >> >
On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers wrote:
>
>
>
> On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau
> wrote:
>
>>
>>
>>
>> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>&
On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris wrote:
> Ralf likes the speed of bento, but it is not currently maintained
>
What exactly is not maintained ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.sci
On Thu, Jun 5, 2014 at 11:48 PM, Nathaniel Smith wrote:
> On Thu, Jun 5, 2014 at 3:24 PM, David Cournapeau
> wrote:
> > On Thu, Jun 5, 2014 at 2:51 PM, Charles R Harris <
> charlesr.har...@gmail.com>
> > wrote:
> >> On Thu, Jun 5, 2014 at 6:40 AM, David Cou
ile", (d) is a change that's worth the bother (this
> determination to include at least canvassing the list to check that
> users in general agree that it's worth it), then yeah we should do it.
> I don't anticipate that this will happen very often given how far
> we've gotten without it, but yeah.
>
Changing the ABI 'safely' (i.e. raise a python exception if changed) is
already handled in numpy. We can always increase the ABI version if we
think it is worth it
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jun 5, 2014 at 2:51 PM, Charles R Harris
wrote:
>
>
>
> On Thu, Jun 5, 2014 at 6:40 AM, David Cournapeau
> wrote:
>
>>
>>
>>
>> On Thu, Jun 5, 2014 at 3:36 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>
1 - 100 of 3514 matches
Mail list logo
