| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This was triggered by the numpy version string (which is unicde)
being included in metadata. This could also solve other problems
for external users of numpy.distutils.
|
|
|
|
|
|
|
| |
Old code used the thread local storage wrong and also only deleted the
directories created for the last parallel build section as the exit
handler only knows about one of the directories.
Fix by storing all created tempdirs to delete at exit.
|
|
|
|
|
|
|
|
|
| |
Revert mingwpy modifications to distutils. They are causing problems
for non-windows builds and it is better to wait until mingypy is
further along.
This reverts commit cda64938eb150b1af6677db4754da3be5fd7e483, reversing
changes made to 8cb3ec6ab804f594daf553e53e7cf7478656bebd.
|
| |
|
|
|
|
| |
python3.5 uses --parallel instead of --jobs
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow extensions using numpy.distutils to compile in parallel.
By passing `--jobs=n` or `-j n` to `setup.py build` the compilation of
extensions is now performed in `n` parallel processes.
Additionally the environment variable NPY_NUM_BUILD_JOBS is used as
the default value, if its unset the default is serial compilation.
The parallelization is limited to within the files of an extension, so
only numpy multiarraymodule really profits but its still a nice
improvement when you have 2-4 cores.
Unfortunately Cython will not profit at all as it tends to build one
module per file.
|
|
|
|
| |
Caused SciPy tests to fail when built with this NumPy.
|
|
|
|
|
|
| |
Add escaping and quoting of dirs and enabled POSIX support in lexer.
Closes #4382.
|
|
|
|
|
| |
This covers those locations that either import or build numarray
or numeric.
|
|
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
|
|
|
| |
This function is no longer required for building with msvc on AMD64
|
| |
|
|
|
|
|
|
|
|
| |
the configuration variables are not a reliable mean to get the shared
library extension. darwin, windows and debug linux are wrong in these
variables.
SHLIB_SUFFIX is also wrong as of python 3.3.1
closes #3057
|
|
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
|\
| |
| | |
2to3: Apply `imports` fixer.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `imports` fixer deals with the standard packages that have been
renamed, removed, or methods that have moved.
cPickle -- removed, use pickle
commands -- removed, getoutput, getstatusoutput moved to subprocess
urlparse -- removed, urlparse moved to urllib.parse
cStringIO -- removed, use StringIO or io.StringIO
copy_reg -- renamed copyreg
_winreg -- renamed winreg
ConfigParser -- renamed configparser
__builtin__ -- renamed builtins
In the case of `cPickle`, it is imported as `pickle` when python < 3 and
performance may be a consideration, but otherwise plain old `pickle` is
used.
Dealing with `StringIO` is a bit tricky. There is an `io.StringIO`
function in the `io` module, available since Python 2.6, but it expects
unicode whereas `StringIO.StringIO` expects ascii. The Python 3
equivalent is then `io.BytesIO`. What I have done here is used BytesIO
for anything that is emulating a file for testing purposes. That is more
explicit than using a redefined StringIO as was done before we dropped
support for Python 2.4 and 2.5.
Closes #3180.
|
|\ \
| |/
|/| |
DOC: Formatting fixes using regex
|
| |
| |
| |
| | |
also other spacing or formatting mistakes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In python3 range is an iterator and `xrange` has been removed. This has
two consequence for code:
1) Where a list is needed `list(range(...))` must be used.
2) `xrange` must be replaced by `range`
Both of these changes also work in python2 and this patch makes both.
There are three places fixed that do not need it, but I left them in
so that the result would be `xrange` clean.
Closes #3092
|
|
|
|
|
|
|
|
|
|
| |
An open file `f` has been an iterator since python2.3 and
`f.xreadlines()` is no longer needed, so replace it with `f`. Also
replace `f.readlines()` with `f` where an iterator will do. The
replacement of `f.readlines()` is not critical because it is a list in
both python2 and python3, but the code is a bit cleaner.
Closes #3093
|
|
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
|\
| |
| | |
2to3: Apply `filter` fixes. Closes #3053.
|
| |
| |
| |
| |
| |
| | |
2to3 does a lot of list(filter(...)) sort of thing which can be
avoided by using list comprehensions instead of filters. This
also seems to clarify the code to a considerable degree.
|
| |
| |
| |
| |
| | |
Generally, this involves using list comprehension, or explicit list
construction as `filter` is an iterator in Python 3.
|
|/
|
|
|
| |
This replaces the `b.func_xxxx` with newer `__xxxx__` attribute names
For example, `f.__name__` replaces `f.func_name`
|
|
|
|
|
|
|
|
|
| |
This removes files and code supporting scons builds. After this change
numpy will only support builds using distutils or bento. The removal of
scons has been discussed on the list several times and a decision has been
made that scons support is no longer needed. This was originally discussed
for numpy 1.7 and because the distutils and bento methods are still
available we are skipping the usual deprecation period.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using numpy.distutils through easy_install caused a RuntimeWarning
because of a failed import of numpy.distutils.
Discussion here:
http://thread.gmane.org/gmane.comp.python.numeric.general/51719
The conclusion seemed to be that the safest fix is to remove the one
line of logging in the relevant callback.
Thanks to Ralf Gommers for the suggestion.
|
|
|
|
|
|
| |
Configuration.add_extension. Configuration.add_library, and Extension. These options
allow specifying extra compile options for compiling Fortran sources within a
setup.py file.
|
|
|
|
|
|
| |
Revert "Introduce new options extra_f77_compiler_args and extra_f90_compiler_args to Configuration.add_extension. Configuration.add_library, and Extension. These options allow specifying extra compile options for compiling Fortran sources within a setup.py file."
This reverts commit 43862759384a86cb4a95e8adb4d39fa1522acb28.
|
|
|
|
| |
Configuration.add_extension. Configuration.add_library, and Extension. These options allow specifying extra compile options for compiling Fortran sources within a setup.py file.
|
|
|
|
|
| |
This is related to PEP 3149, tags in shared library extensions. Only applies
to Linux (for now). See also #1749.
|
| |
|
|
|
|
| |
make_hg_version_py method, get_version supports hg revision.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Universal builds break the configure stage: we have to harcode the
arch-specific values in the case of mac os x, as we have only one configuration
stage per compile, but several arch per compile with the braindead -arch
machinery.
We rename the old numpyconfig.h to a private header, and numpyconfig.h itself
post-fix the values in the case of mac os x.
|
| |
|
| |
|
| |
|