Repository navigation
revisit Spec 0 #4449
Description
According to https://scientific-python.org/specs/spec-0000/#support-window, we are nearing the end of the support window for python 3.12, and Spec 0 compels us to drop support for 3.12 when that window closes.
Should we actually do this? My feeling is that Python 3.12 support hasn't been a problem for our codebase, and I'm not aware of any python 3.13 features we desperately need. I know that Spec 0 is manifestly about ecosystem concerns and not problems within a codebase, but I'm not sure that zarr supporting python 3.12 has a sizable impact on complexity of software testing in the python ecosystem. So I see costs: alienating users, churn, etc, and no benefits to dropping 3.12 just because other packages will drop support for it. If zarr had a different role in the python ecosystem I might see things differently, but IMO stability is very nice to have, and I don't see a compelling reason to be unstable here.
Activity
tlambert03 commentedon Sep 30, 2026
I am a big opponent of Spec 0, and I think it causes more harm than good. I definitely understand why any specific repo would make the decision to drop support for older python versions before the official python EOL date (particularly in the case libs with C-extensions, more challenging build pipelines, or abi compatibility challenges, like numpy or matplotlib), and I also sympathize with over-worked developers wanting to reduce their workload. But I think codifying this as a general recommendation for the ecosystem was a mistake. Particularly in the case of packages like zarr-python that ship a simple
py3-none-anywheel, I see little reason why we should be compelled as a rule to rip out support for a version of python (that we already support) prior to it's EOL date.It does have a cost, and I have definitely avoided depending directly on zarr-python in some of my projects (opting to guard it behind an extra) specifically because it obeys Spec 0.
Spec 0 works better for something like numpy or matplotlib that have rather stable APIs, where, if a downstream package needs to support all current versions of python, they can usually find a workable solution depending on a slightly older numpy version or adding a few conditionals. But the zarr-python v3 changes combined with the spec0 adherence did definitely cause headaches for parts of the community. I would love to see zarr-python just follow the standard python EOL schedule (i.e. just dropping 3.10 this october... let alone dropping 3.12 already). Or, at least aim to gradually return to the standard schedule once 3.11 goes EOL.
d-v-b commentedon Sep 30, 2026
I'm up for this!
jacopoabramo commentedon Oct 2, 2026
Hey, sorry for interjecting, SPEC 0 has definetely caused blunders for me as well. I'm quite conflicted because on one hand I like the idea; on the other hand I've experienced first hand how annoying it becomes to support a SPEC 0-compliant dependency when a project wants to support the regular EOL cycle. I know that it's not zarr-python responsability, but I'm wondering if dropping back to EOL would cause a little bit of concern in the scientific python community. Has somebody tried to reach out more projects about this? What's their feeling?
tlambert03 commentedon Oct 2, 2026
I don't think anyone in the sci py community would have any concerns about any other package in the community supporting a broader set of Python than spec 0 requires. The goal is not to enforce a small subset of Python support, it's to relieve developer burden for overworked and complicated packages. But those developers don't mind if other packages want to support a superset of their restricted set
d-v-b commentedon Oct 8, 2026
so I'm not hearing any voices asking that we drop dependencies per the spec 0 schedule, so I'm going to open a PR against the specs repo to get zarr off the drop chart.
jarrodmillman commentedon Oct 8, 2026
SPEC 0 recommends you drop Python 3.12.
jacopoabramo commentedon Oct 8, 2026
But if it doesn't get dropped, is it really following SPEC 0 then? Is napari (which is not dropping 3.11) not following SPEC 0, for example?
jacopoabramo commentedon Oct 8, 2026
Just as a footnote: I'm a prospective user of zarr who always tried to use it but was always cutoff (especially with the transition from zarr 2 to 3) due to SPEC 0. The reason being I develop software targeted for hardware acquisition, interacting a lot with device vendors, who rarely follow strict release procedures but offer python SDKs which lag way behind the Python versions. And supporting these + supporting SPEC 0 is daunting.
d-v-b commentedon Oct 8, 2026
whether it's a recommendation or a requirement (which is apparently how we erroneously interpreted things), I dont think we should abide by it
Remove zarr from spec0 drop table (#439)
d-v-b commentedon Oct 27, 2026
im closing as completed. we will decide for ourselves when to drop dependencies.