@jakevdp what do you think about stopping Python 2 support for the Altair 2.0 release?
I'd be open to that... the one hesitation is that I'd like it to be usable from Colab, and much of google's code-base still defaults to 2.7.
Is there any real sticking point in making things 2.7-compatible?
I have been writing code today using Python 3 type annotations. Being able
to declare types and run mypy during development is a game changer (I have
become spoiled writing lots of TypeScript) - especially in designing clean,
consistent, rational APIs. We could change over to using the comment forms
of the type annotations, but it is a pain to write all of them in comments.
Those are the main things that are coming up so far, but there might be
other things. The other point is that current versions of IPython are
Python 3 only - there is work we are doing in the display system, and I
don't want to get into a situation where we can't move forward with using
that stuff. A lot of that work is being done for libraries such as Altair.
On Sat, Feb 10, 2018 at 2:36 PM, Jake Vanderplas notifications@github.com
wrote:
I'd be open to that... the one hesitation is that I'd like it to be usable
from Colab, and much of google's code-base still defaults to 2.7.Is there any real sticking point in making things 2.7-compatible?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/altair-viz/altair/issues/444#issuecomment-364701407,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0Paan6UgHh8JHcK-daN9gSpPoFUNks5tThoBgaJpZM4SBAvQ
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]
Makes sense to me... would be curious to hear @craigcitro's thoughts on this.
This would be a real blow to altair use inside Google (and for internal use in Colab) -- Google is still using python2, so it'd mean that we'd put all plans to direct people to altair on ice until we had better python3 support. (This is still pretty far off, and in large part out of our hands.)
I also don't know offhand what %age of external colab users are still using python2, but I know it's nonzero, so it probably means we'd want to wait on pushing altair in our external samples, instead favoring just direct use of vega/vegalite and libraries like pdvega.
Maybe I sit in a different part of the world, but over here, "python3 only library" still feels a little user-hostile: people wanting to switch and people being able to switch are often two different things. For something like the notebook code, where I can let python3 run that code and still talk to a python2 kernel, it's not a big deal; for a library, it feels discouraging.
If the main motivation is the use of type hints in development, we could use an approach like strip-hints to post-process the code and make it compatible with 2.7.
Much of the open-source pydata ecosystem is moving to python 3 only releases in the next year or have done so already:
http://www.python3statement.org/
Even if we support Python 2.7 in this repo, it is very likely that users will soon hit difficulties with other packages in the ecosystem. For example, here is what NumPy's strategy is:
"Starting on January 1, 2019, any new feature releases will support only Python3."
While I don't have any interest myself in supporting Python 2 actively, I am fine if someone else wants to keep things working on Python 2.7 in the same source tree for now. I have started to use type annotations in places, but we can move those over to being comment based.
After working all weekend on this for free, I don't feel too bad taking this stance relative to a >$700B company ;-)
That makes sense, Brian.
One other data point: one reason I have so much time to invest in Altair right now is because that company saw fit to hire me half-time to work on it. So if we go this route, many of my own cycles will be spent figuring out ways to undo Python 3-only features in the codebase, at least for the next 7 months or so.
Would you be terribly offended if I converted your code to be Python 2.7 compatible, and committed it back to the repo? Or would you prefer that that kind of effort be done in a fork?
Sorry I wasn’t clear - I am completely fine with someone supporting python 2.7 in the repo. I imagined that someone might be you, but didn’t want to speak for you or you employer.
Sent from my iPhone
On Feb 12, 2018, at 5:36 AM, Jake Vanderplas notifications@github.com wrote:
Would you be terribly offended if I converted your code into Python 2.7 compatible code, and committed it back to the repo? Or are you committed to not supporting Python 2.7 at all within the repo?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
OK, sounds good. From what you were saying above, I wasn't sure how central to the design the 3-only features were.
I'll think about how we can best support Python 2.7 given what you've written so far.
This is an issue I'd be happy to help with as my next Altair adventure. Is it something I can just dive in on by running the unit tests against Python 2.7? Or are you aiming to do some more invasive surgery yourself first?
Funny, I was just planning to start tackling this this afternoon. I think this is what will be required:
If you'd like to start looking at that @palewire, that would be great!
Hey @palewire – let me know if this is something you're working on, otherwise I'll plan to work on it myself. Thanks!
I'd like to attempt it in the next week or two, though I can't guarantee any particular time and date.
OK – I need this relatively soon, so I'm going to take a look at it this morning.
I totally understand. If you scope it out and see something you'd like to assign let me know.
Altair 2.0 now supports Python 2. We can re-evaluate in the future whether we'd like to drop that support; for now it's important for some users (namely Google Colab).