| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TST: added test for issue #18684
ENH: f2py opens files with correct encoding, fixes #635
TST: added test for issue #6308
TST: added test for issue #4519
TST: added test for issue #3425
ENH: Implement user-defined hooks support for post-processing f2py data structure. Implement character BC hook.
ENH: Add support for detecting utf-16 and utf-32 encodings.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
`global` is only needed if a variable appears on the left of an assignment.
These variables do not.
Most suffer from the misconception that `var[x] = y` requires `var` to be global, but it does not.
|
| |\
| |
| | |
MAINT: Fixing typos in f2py comments and code.
|
| | | |
|
| |/
|
|
| |
Signed-off-by: Changqing Li <changqing.li@windriver.com>
|
| |
|
|
|
|
|
|
| |
* The instance in `_internal` is parsing tuples and integers, so `ast.literal_eval` is just fine
* The instance in `crack_fortran` is just trying to lookup a function name dynamically
* The instance in `f90mod_rules` is looking at the result of `capi_maps.getarrdims(...)['rank']`, which is always a string representation of an integer
The f2py code is still littered with `eval`, but the remaining cases were harder to reason about.
|
| |
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The files
* capi_maps.py
* crackfortran.py
* f90mod_rules.py
previously used `from .auxfuncs import *` and also called `eval`
without an explicit enviroment. An attempt to use explicit imports
led to errors, and because static code analysis in not sufficient
to determine what functions need to be imported, it is safest to
continue using `import *` pending a major refactoring of f2py.
Closes #6563.
|
| |
|
|
|
|
|
| |
The fixes are generated by autopep8, which uses line continuation.
There are 441 cases that it is unable to handle, involving strings, and
that is more, and more delicate, work than I want to do at this time.
The line continuation characters at least mark some of the long lines.
|
| |
|
|
|
| |
Decided to bite the bullet on this one. The code is certainly more
readable, so should be easier to fix if we need to.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idioms fixer makes the following replacements.
1) int <- bool
2) comparison or identity of types <- isinstance
3) a.sort() <- sorted(a)
There were two problems that needed to be dealt with after the
application of the fixer. First, the replacement of comparison or
identity of types by isinstance was not always correct. The isinstance
function returns true for subtypes whereas many of the places where the
fixer made a substitution needed to check for exact type equality.
Second, the sorted function was applied to arrays, but because it treats
them as iterators and constructs a sorted list from the result, that is
the wrong thing to do.
Closes #3062.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Python 3 `map` is an iterator while in Python 2 it returns a list.
The simple fix applied by the fixer is to inclose all instances of map
with `list(...)`. This is not needed in all cases, and even where
appropriate list comprehensions may be preferred for their clarity.
Consequently, this patch attempts to use list comprehensions where it
makes sense.
When the mapped function has two arguments there is another problem that
can arise. In Python 3 map stops execution when the shortest argument
list is exhausted, while in Python 2 it stops when the longest argument
list is exhausted. Consequently the two argument case might need special
care. However, we have been running Python3 converted versions of numpy
since 1.5 without problems, so it is probably not something that affects
us.
Closes #3068
|
| |
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
to functions
|
| |
|
|
| |
PEP8 conformance (only one import per line).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
ticket #147.
|
| |
|
|
| |
extraneous whitespace
|
| | |
|
| |
|
