Comments (4)
This is very true. I've been thinking about this over the past few weeks, and I think I'll finally have some time to actually work on this coming up. Clearly, the print statements will need to be changed, but that should just be a matter of putting parentheses around all the things to be printed (apparently this works in both Python 2 and Python 3, which I didn't know). I haven't really used Python 3, so do you have any thoughts on anything else that could clearly go wrong?
from pykrige.
I don't think there would be that many changes to make the code base compatible with both Python 2.7 and 3.x (see this cheat sheet ). First thing could be to add,
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
at the top of every .py
file to make 2.x behave like 3.x. Then replace all print 'this'
with print('this')
and other minor issues if any arise when running the test suite ( six
module would be very usefull there).
The only real issue I see is that the Cython BLAS binding I did won't work with 3.x as far as I remember. So the solution is either to try fixing that, or ask for >=scipy-0.16
as minimum requirements which includes those bindings now (and this transition should be done at some point anyway). I'll look in that last point as soon as I can (probably mid november) but for now I suppose we can just disable the compilation of the Cython backend in setup.py
for Python 3.x (for instance checking with if six.PY3
etc.).
from pykrige.
Alright, I've updated the code so that it should be Python 3 compatible. (The new version is also on PyPI.) The tests on TravisCI and AppVeyor are passing with when run with the Python 2.7 and Python 3.4 platforms. I've also updated the setup script to try to better address the Cython compiler issue with Windows (as discussed in issue #8). Now the script attempts to build the Cython extensions regardless of operating system or build_ext compiler settings, and if the build fails it falls back to a pure Python implementation without building the Cython extensions. (I followed the example set here.) Also, the setup script currently does not build the Cython extensions for Python 3. This can be easily changed in the future.
One thing that I am slightly concerned about is the way I'm currently using strings in the setup script. I couldn't use the little from __future__ import unicode_literal
thing to just force all the strings to be unicode, because setuptools.Extensions
requires the name of the extension to be a native string in Python 2.7 rather than unicode. So I left all the strings as unspecified format strings, which seems to be working OK regardless of whether the script is run on Python 2.7 or Python 3.4. But I might be missing something subtle here. Let me know what you think.
from pykrige.
Awesome! This works really well. About the unicode in setup.py
, I think leaving as it is now should be good (I have not seen anyone using that import in setup.py
anyway). So this solves the issue on the Python 3 support, and I'll look into updating Cython bindings as as soon as I can.
from pykrige.
Related Issues (20)
- CI broken
- Consider the height when kriging #Pykrige
- M1 Silicon Build (linux/arm64) HOT 1
- Export kriging as raster
- AttributeError: 'UniversalKriging' object has no attribute 'external_Z_array' HOT 2
- Incompatible with SciPy 1.9.0, AttributeError on scipy.linalg.pinv2 HOT 2
- GSTools 1.4 requirement for PyKrige 1.7
- Bug: Problem with exact_values when ordinary kriging with backend = 'C' HOT 2
- search radius HOT 3
- Bug: pykrige.ok using deprecated function from SciPy 1.7.0 HOT 1
- Excessive memory use creating OrdinaryKriging object (even if not estimating variogram) HOT 1
- Memory Issue with Large Dataset
- How do you save a model once you fit it
- kr and ck are not imported in __init__.py HOT 1
- `x0` is infeasible.
- uk3d.execute prints statement of 'Executing Ordinary Kriging' HOT 1
- The result is very difference with arcmap, and result grid missing maximum value.
- Can variogram start at zero distance?
- Bug variogram_model parameter ? HOT 1
- zero-size array Erro in OrdinaryKriging HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pykrige.