-
Notifications
You must be signed in to change notification settings - Fork 6.8k
[DISCUSSION] python2 deprecation #8703
Comments
I vote for deprecating support for python2. According to the website, python2 will not be maintained after 2020: https://pythonclock.org. Also, python3 is really easy to use and it’s straightforward for python2 users to switch to python3. |
Let's worry about that when 2020 comes. |
Let's wait until numpy deprecate it first. |
Many linux versions has python 2 as default, so I think talking about deprecation is little early. |
The easy choice would be to simply copy numpy's decision and drop python2 the same time they do. In the meantime, it cannot hurt to encourage users to switch now. I can think of few good reasons to still be using python 2.7 at this point. |
I'm assuming there are still a lot of production customers who are using Python2 and will continue to do so for some foreseeable future. These customers may/will be reluctant to move to Python3 until they are really forced to (either due to lack of support for python2 or new features in python3). If we deprecate python2 too "soon", the chances are we are going to face wrath of such customers and it may not provide a happy customer experience. (Unless there is a specific feature that can't be handled w/ python2) We can let customers/developers (and rest of the python ecosystem?) move to python 3 on their own while we continue to support python2. Probably around 2019 and early 2020, we'll see a lot of people moving to python3. It may then be a good time to seriously consider deprecating python2. |
synchronization with numpy,stop add new feature when 2019.1.1 |
Closing for now. Reopen in 2 years maybe. |
@piiswrong very exact prediction +1 for proposal, measuring for MKLDNN and there is NO performance and functionality issue. |
+1. It's time to stop. |
synchronization with numpy The reason is that some projects like DeformableConvNets doesn't support Python3 yet. I think it will be more friendly if we keep the compatibility with Python2 until numpy deprecates Python2. |
Pipe dream: I'd love it if Mxnet not only dropped Python 2 support for a more consistent design, but also went all in on Python 3.6 for type hint integration. There are enough different types involved in MXNet that types can help clarify usage, particularly for disambiguating symbol vs ndarray vs list vs tuple; tuple of ints rather than tuple of floats; etc. |
As part of the transition we also need to go through all the examples we supply with MXNet and explicitly check they are compatible and running using Py3. |
The 2020 is coming, is there any conclusion? |
Given the opportune time of mxnet 2.0 development, let's drop python2 support in mxnet 2.x |
I think we should drop python2 in mxnet 2.x. Also, we should revise all the docstrings to use type hints: https://docs.python.org/3/library/typing.html. |
MXNet 1.6.x is the last release to support Python 2. See #15990 |
Given that our dependency, numpy, is dropping support for python 2.7 soon, where do we stand?
Update:
Reopening this conversation now that python projects are all pledging for dropping support for python2. This would help modernize the design and engineering practice in MXNet to help improve speed and quality.
If the consensus is towards the direction of dropping python2 support, I suggest we announce our plan to drop python2 support in the next release, and actually drop the support in the next major version. Thanks.
The text was updated successfully, but these errors were encountered: