| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Note that since we now need `npy_3kcompat.h`, we can delete all duplicated lines in this file
We preserve the original exception type for compatibility with old code here.
|
| |
|
|
|
|
|
| |
This makes sure to undef at the end, and by putting the define in the
C code it ensures that the error message is understandable.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Use PyUString_FromStringAndSize defined in npy_3kcompat instead. Not
using bytes may cause some problems, but strings seem like a better
choice. As modules generated with current f2py error out, this
particular use is not common and we are free to choose.
Closes #4256.
|
|
|
|
|
|
|
|
|
|
| |
Because Numpy 1.8.0 will no longer supports Python versions < 2.6 we
no longer need to check for that and can also remove the code that is
specific to those earlier versions.
To make this a bit safer, the toplevel setup.py file now contains a
check of the Python version number and raises an error when run by an
unsupported version.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a few exceptional cases where symbols are shared between different
Python modules the use of `PyArray_API` in f2py (fortranobject.h)
conflicts with the regular use of the same symbol in the multiarray
module. Generally the symptom of this conflicting use is a segfault
when importing a f2py'ed module. This occurs because the module init
code somehow overwrites the first element of `PyArray_API` with the
location of `PyArray_API`, causing a crash when
`PyArray_GetNDArrayCVersion` is called.
Closes gh-2521.
|
|
|
|
| |
on Python 2.x
|
|
|
|
|
|
|
| |
compatibility functions in npy_3kcompat.h to replace the current calls.
This gets rid of a number of version checks and is easier to maintain.
Fix bug that was present in the ufunc _loop1d_list_free destructor in
the python3k case.
|
| |
|
| |
|
|
|
|
| |
after using intent(align8) in the corresponding scipy pyf files.
|
| |
|
| |
|
| |
|
| |
|
|
|