Conversation
|
It's such a liberating feeling, isn't it? |
|
As an outsider who's been thinking about incorporating I've been toying with the idea of trashing all my PVGeo file IO for GIF Tensor/Tree Meshes and other Still having Python 2.7 support would allow me to make PVGeo algorithms that call back to Me needing Python 2.7 support would only last until ParaView upgrades its Python to 3.6 which I believe is scheduled for Summer 2019. Don't let this hold back progress though! |
|
What about having Edit: It would obviously be |
|
@prisae, that would work fine! I could then set PVGeo's dependency as v0.3.3 and any VTK interfaces needed for |
|
Hi @banesullivan, thanks for chiming in! We can definitely continue to support in terms of bug fixes in the mean-time. P.S. I added you to the SimPEG org 🎉. I am thrilled that you are interested in interfacing to discretize - having accessible 3D viz is something that would have a very big impact! |
|
Wow, thanks @lheagy!!! I am definitely interested interfacing |
Codecov Report
@@ Coverage Diff @@
## master #111 +/- ##
==========================================
- Coverage 72.99% 71.43% -1.57%
==========================================
Files 20 20
Lines 4503 4589 +86
==========================================
- Hits 3287 3278 -9
- Misses 1216 1311 +95
Continue to review full report at Codecov.
|
prisae
left a comment
There was a problem hiding this comment.
I think this would be a good point to clean-up the code base from stuff like from __future__ import print_function, as those are mostly obsolete now.
setup.py
Outdated
| version="0.4.0", | ||
| install_requires=[ | ||
| 'numpy>=1.7', | ||
| 'scipy>=0.13', |
There was a problem hiding this comment.
How about taking the opportunity and crank up the scipy-requirement? Ideally at 1.0? But that might be too high. Anyway, 0.13 is a bit low, and leaving Python 2 behind might be a good point to adjust.
There was a problem hiding this comment.
It might be a bit pushy. But it was released a year ago, and it was a big release (many changes), so it might make it easier...
setup.py
Outdated
| @@ -78,5 +78,6 @@ def configuration(parent_package='', top_path=None): | |||
| platforms=["Windows", "Linux", "Solaris", "Mac OS-X", "Unix"], | |||
| use_2to3=False, | |||
- remove imports from __future__ - update scipy requirement - only specify additional requirements for development in the requirements_dev.txt (e.g. don't include requirements described in the setup.py)
…nto no_more_py27
add python 3.7 to testing
|
Would it be possible merge #114 to v0.3.x and deploy on PyPI before this bump to 0.4.0? |
|
Yep, we can plan to do that @banesullivan. I am just not sure what is causing the upstream errors on python 2.7... it is failing on the pip install (I am sort-of hoping other groups are running into this and it will resolve itself, but it has been close to a week...) |
|
Thanks @prisae - definitely forgotten :) |
| ): | ||
| return self.reshape(x, xType, outType, format) | ||
|
|
||
| def reshape(self, x, xType='CC', outType='CC', format='V'): |
There was a problem hiding this comment.
I think we should also rethink input variable names here (e.g. format should not be used). What about
def reshape(self, x, x_loc='CC', out_loc='CC', out_format='V')I think "loc" is a bit more descriptive (and even "location"). I am still not sure about "format". (It should also take "vec", "vector", "matrix" to let the user be a bit more flexible in the input).
Thoughts?
cc @rowanc1
|
Most of this was implemented in #227 instead. |
add an f-string to the copyright in the init.py
remove testing on python 2.7 on both travis and appveyor
include
requires_python >= 3.6in the setup.pyI suggest we move to version 0.4.0 with this pr