-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What to do with Python 2 #432
Comments
Delete Python2! |
No disagreement from me. Users can pin to the last tag to support Py2 if they want it. Or build + install on their own. No reason we have to keep supporting the Python Classic at this point. |
Hi @minrk , any more reason that you wanna remove python2? Like performance issue, introduce bug, or conflict? |
@minrk mentioned it wastes space, which I completely agree with. Here's another: Python 3 was released in December 2008. The (finalized, much-discussed, much-worked-over) PEP 3000 introducing Python 3 goes back even further, to 2006. I was inspired to put on my big kid pants and switch to Python 3 when a library I used eliminated Python 2 support - hopefully this move will do the same for others. And when Python cookbooks/guides started being rewritten for Python 3. If a library you use doesn't support Python 3, that's a good reason to (a) search for alternatives, (b) open an issue to request they switch to Python 3, or (c) try out some tools like 2to3 and make a PR to help them switch. There are plenty of tools to support the transition:
Also 3 cheers for the "opinionated stacks" point - pip pip, hooray! |
We have limited time to maintain software, including distribution channels like this. If you want Python2 support, you'll need to run your own image. You're free to use the old Python2 setup for it, maintaining it however you choose. |
Right now,
scipy-notebook
sets up a full scientific Python stack for Python 2, and there are currently no images that have a reasonably complete stack without a big legacy install next to it. That seems pretty wasteful.We should consider when/how to push Python 2 out of the default images. Options include:
The first option would be my preference. Derivative images can always
conda create -n python2 python=2 ipykernel
.The result of these would be that descendant images (datascience, pyspark, tensorflow) would all lose Python 2. I think that's a good thing, given that these are supposed to be "opinionated stacks", and my opinion is that nobody should be using Python 2 with Jupyter :)
The text was updated successfully, but these errors were encountered: