Skip to content

drop support for python 2.7#111

Closed
lheagy wants to merge 22 commits intomasterfrom
no_more_py27
Closed

drop support for python 2.7#111
lheagy wants to merge 22 commits intomasterfrom
no_more_py27

Conversation

@lheagy
Copy link
Member

@lheagy lheagy commented Oct 24, 2018

  • 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.6 in the setup.py

  • I suggest we move to version 0.4.0 with this pr

@leouieda
Copy link
Member

It's such a liberating feeling, isn't it?

@banesullivan
Copy link
Member

banesullivan commented Oct 24, 2018

As an outsider who's been thinking about incorporating discretize with some of my projects, I would still need Python 2.7 compatibility.

I've been toying with the idea of trashing all my PVGeo file IO for GIF Tensor/Tree Meshes and other discretize-friendly data formats. Then simply use the VTK interfaces already in discretize (I would also create VTK interfaces where they are missing in discretize and ensure the existing ones are good to go).

Still having Python 2.7 support would allow me to make PVGeo algorithms that call back to discretize and have a graphical user interface for discretize directly in ParaView. This would look similar to GMSGDataExchange/omf#27 which unfortunately won't be happening because the VTK interface in omf would have to be separated.

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!

@prisae
Copy link
Member

prisae commented Oct 24, 2018

What about having v0.3.3 on bug-fix-support till the end of 2019, but v0.4.0 and future ones are Python 3 only? This would be the same as numpy/scipy will be anyway, just two months earlier. Or do you think you will need new features in discretize as well @banesullivan?

Edit: It would obviously be v0.3.x with only bug-fix-support, as any bug-fix would increase the version number. So you could fix the dependency to v0.3, and v0.4 and following are Python 3 only.

@banesullivan
Copy link
Member

@prisae, that would work fine!

I could then set PVGeo's dependency as v0.3.3 and any VTK interfaces needed for discretize that are not currently implemented, I will add directly in PVGeo. Then once ParaView upgrades to Python 3, I would migrate those VTK object interfaces into discretize so classes like CurvilinearMesh, CylMesh, etc would have toVTK() methods like the _toVTRObj method in MeshIO.

@lheagy
Copy link
Member Author

lheagy commented Oct 26, 2018

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!

@banesullivan
Copy link
Member

Wow, thanks @lheagy!!! I am definitely interested interfacing discretize into my 3D viz projects in @OpenGeoVis so this will be the perfect way to start collaborating!

@codecov
Copy link

codecov bot commented Oct 26, 2018

Codecov Report

Merging #111 into master will decrease coverage by 1.56%.
The diff coverage is 40.35%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
discretize/CylMesh.py 91.55% <ø> (-0.02%) ⬇️
discretize/utils/coordutils.py 83.33% <ø> (ø) ⬆️
discretize/utils/__init__.py 100% <ø> (ø) ⬆️
discretize/utils/meshutils.py 74.19% <ø> (-0.81%) ⬇️
discretize/utils/interputils.py 80.55% <ø> (-0.53%) ⬇️
discretize/utils/matutils.py 92.88% <ø> (-2.06%) ⬇️
discretize/Tests.py 78.53% <100%> (-0.11%) ⬇️
discretize/View.py 18.25% <100%> (-0.12%) ⬇️
discretize/InnerProducts.py 97.42% <100%> (ø) ⬆️
discretize/TensorMesh.py 90.36% <100%> (-0.03%) ⬇️
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7bc916a...f14e177. Read the comment docs.

Copy link
Member

@prisae prisae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good call >= 1?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use_2to3: obsolete?

- 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)
Copy link
Member

@prisae prisae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me now.

@banesullivan
Copy link
Member

Would it be possible merge #114 to v0.3.x and deploy on PyPI before this bump to 0.4.0?

@lheagy
Copy link
Member Author

lheagy commented Oct 28, 2018

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...)

Copy link
Member

@prisae prisae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lheagy , you replaced absolute imports by relative imports for the Py2->Py3 switch in most files. However, not in

  • __init__.py
  • DiffOperators.py
  • InnerProducts.py
  • View.py

Forgotten or is there a particular reason?

@lheagy
Copy link
Member Author

lheagy commented Oct 30, 2018

Thanks @prisae - definitely forgotten :)

):
return self.reshape(x, xType, outType, format)

def reshape(self, x, xType='CC', outType='CC', format='V'):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@prisae
Copy link
Member

prisae commented Aug 26, 2020

Talking about Python 3.5 over in #219 it seems odd that this PR is still open. Could we merge this @lheagy ?

@prisae prisae mentioned this pull request Sep 28, 2020
@jcapriot jcapriot closed this Nov 17, 2020
@prisae
Copy link
Member

prisae commented Nov 18, 2020

Most of this was implemented in #227 instead.

@jcapriot jcapriot deleted the no_more_py27 branch August 19, 2021 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants