| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is necessary to handle some cases where scons scripts and packages
are not in the same directory.
|
| | |
|
| | |
|
| |
|
|
| |
directly - we can feed that to scons easily.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
additional directories.
|
| |
|
|
| |
current package.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
generation/handling.
|
| | |
|
| | |
|
| | |
|
