-
-
Notifications
You must be signed in to change notification settings - Fork 305
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
When will Zarr drop Python 2 support? #393
Comments
Fair point to raise. Most of the headache around this IMO has been on the compression side (Numcodecs) and not so much in Zarr proper. We've done a pretty good job in 0.6 by cutting down the amount of legacy code, which does make this a bit less painful. For Numcodecs IMO (though feel free to share other opinions) we should aim to drop Python 2 in Numcodecs 1.0.0. IDK whether that should just be the next release of Numcodecs or if we need a few more minor releases. Not sure if we need a legacy maintenance branch, but 0.x (perhaps even a specific minor like 0.6) could remain for legacy Python support (much like is the case for NumPy and SciPy). Thoughts on this are welcome. For Zarr personally I'd be interested to see 2.3.x support Python 2. Am not sure whether that should happen in 3.0.0 or earlier. The trick with 3.0.0 is that will likely include some adjustments to the spec and I don't think we should hold up dropping Python 2 for that reason. Though admittedly we could push the spec changes off to 4.0.0. Would be curious to hear what others think about this. |
My 2c... For zarr I think we should keep PY2 support for the 2.3.x series, as we are nearly there. After that I'd like to drop PY2 support ASAP. For numcodecs I'd like to drop PY2 support ASAP. I don't think there's any reason to wait. Should we have a legacy maintenance branch for zarr and/or numcodecs? It would be nice of course, but I'm not sure I'd have the time to set it all up and handle backporting any non-trivial bug fixes. Could we live without it? PY2/3 compat has burned so much of my time, I just can't afford any more. |
FWIW I'd be happy to say community members will have to submit PRs to backport fixes and not actually worry about them ourselves. |
That sounds like a good compromise.
…On Tue, 29 Jan 2019, 08:29 jakirkham ***@***.*** wrote:
FWIW I'd be happy to say community members will have to submit PRs to
backport fixes and not actually worry about them ourselves.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#393 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAq8Qo23LSieg6TIcYDsRjD1jJ5YVnc1ks5vIAZmgaJpZM4aDzs3>
.
|
FWIW there is the MrMeeseeks bot, which can be used to automate this backporting. For instance, scikit-image uses this to maintain their Python 2 LTE branch. |
That's cool.
FWIW I still don't think I can commit to maintaining a Python 2 LTS branch
until Python 2 EOL, but if anyone wants to activate the MrMeeseeks bot and
use it to maintain a PY2 branch on a best-effort basis I have no objection.
…On Tue, 19 Feb 2019 at 05:39, jakirkham ***@***.***> wrote:
FWIW there is the MrMeeseeks bot <https://meeseeksbox.github.io/>, which
can be used to automate this backporting. For instance, scikit-image uses
this to maintain their Python 2 LTE branch.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#393 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAq8Qpr20YT6D0KL7NR-UnurkchL6l93ks5vO44WgaJpZM4aDzs3>
.
--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health
Big Data Institute
Li Ka Shing Centre for Health Information and Discovery
University of Oxford
Old Road Campus
Headington
Oxford
OX3 7LF
United Kingdom
Phone: +44 (0)1865 743596 or +44 (0)7866 541624
Email: [email protected]
Web: http://a <http://purl.org/net/aliman>limanfoo.github.io/
Twitter: @alimanfoo <https://twitter.com/alimanfoo>
Please feel free to resend your email and/or contact me by other means if
you need an urgent reply.
|
I think I would like to hear from someone using Zarr and Python2 before choosing to maintain any backward compatibility. I'm not convinced there are any (enough) Python2 users at this point (based on the pypistats link above). |
I am all for dropping py2; but there are probably many people who simply don't install/update package much because long-term stability is exactly what they need. Would such people ever go for something cutting-edge like zarr? Probably not. |
If they "don't install/update package much", why does it matter what gets added removed from zarr now? |
That's more or less what I meant, but of course there is a difference between rarely and never. |
Just to mention that supporting Python 2 is getting awkward with latest releases of numpy, pytest and s3fs all dropping numpy support. I think we should drop Python 2 for the next release, i.e., a PR to drop Python 2 support is welcome any time from now. (Also same upstream for numcodecs.) |
Yeah we are also now months away from the EOL of Python 2. |
I have a PR open to drop Python 2: #470. |
Zarr still supports Python 2. As we all know, more and more of the scientific Python ecosystem is moving to Python 3 only. Looking at PyPI stats, it seems this compatibility is rarely used. Is now an okay time to discuss when and how to sunset Python 2 support here?
From my limited experience, maintaining Python 2 support makes development a bit harder (and annoying). Particularly when sorting out various string encoding/decoding issues that are relatively common in Zarr.
The text was updated successfully, but these errors were encountered: