Zstandard in the standard library (PEP 784)

[Rogdham]

As you may know, Python 3.14 introduces the compression.zstd module, which adds native Zstandard support to the standard library (PEP 784). It also adds support for Zstandard in the zipfile module.

For older versions of Python, the backports.zstd library is available.

---

I have locally applied the following patch to your tests:

diff --git a/test/test_zipfile.py b/test/test_zipfile.py
index 4f39ea6..5bccef0 100644
--- a/test/test_zipfile.py
+++ b/test/test_zipfile.py
@@ -13,8 +13,10 @@ mydir = os.path.abspath(os.path.dirname(__file__))
 sys.path.append(os.path.join(mydir,'..'))
 os.chdir(mydir)
 
-import zipfile
-import zipfile_zstd
+if sys.version_info >= (3, 14):
+    import zipfile
+else:
+    from backports.zstd import zipfile
 
 info7z  = subprocess.check_output(['7z', 'i'])
 avail7z = {

Then, I ran the tests without installing zipfile-zstd, and they passed successfully on both CPython 3.14.0rc3 and CPython 3.13 (once backports.zstd library is installed).

---

So unless I'm mistaken, this suggests that the zipfile-zstd library is not needed anymore for users of Python 3.14+ or those using the backport.

Perhaps it is time to consider deprecating the package? I imagine this might bring mixed feelings, and I completely understand as I am going through a similar process for pyzstd. Of course, the decision is entirely yours.

I am taking this opportunity to thank you for this package. While I have not used it personally, the issues on GitHub suggest that it was helpful to the community. Thank you for bridging the gap until “the batteries” are included in Python itself!

[Akaricchi]

Hello, thanks for the heads up.

I'm aware of (and very excited for) zstd finally coming to the standard library. My plan for this project was to simply re-export the zipfile module on python >= 3.14, if python is actually built with zstd compreession support (unfortunately this is currently not the case for some distributions, such as openSUSE's).

My personal use-case (and original motivation) for this project is the Taisei resource packaging script. I have not tested it yet, but it looks like your backport can work as a drop-in replacement, so long as the ZstdDecompressor class is compatible with the one from python-zstandard.

One advantage of this module is that because it's very small and python-only, we can easily include it in the Taisei source code as a submodule without an installation requirement. The python-zstandard module that it depends on is widely available and packaged by Linux distributions, and it is the only build-time Python dependency that we have, so we can instruct our users to install it from their package manager instead of having to set up a venv. On some distributions, pip will complain loudly when attempting to install even user packages without a venv these days.

I think what I will do is, once I've confirmed that it works, start preferring backports.zstd in Taisei, falling back to python-zipfile-zstd and python-zstandard with a deprecation warning. I hope that will encourage package maintainers to ship backports.zstd, and once it's more widely available we can deprecate my package altogether.

One small nitpick I have about your backport is the stated inability to be installed on python 3.14, because of the above issue I mentioned with some Python builds not having zstd enabled. If the backport could be installed on those builds, the compat snippet could look like this:

try:
    from compression import zstd
except ImportError:
    from backports.zstd import zipfile
else:
    import zipfile

Though I hope that we can just push distributions to enable zstd universally.

[Rogdham]

You make very good points about the availability of zstandard in Python 3.14 at runtime. This seems to have a lot of implications, so I need to think about this some more before being able to answer.

For your packaging script, I would first try to see if using the zipfile module of Python 3.14 (or the backport) would work directly without needing to compress manually (in other words: maybe the write_zst_file function is not needed anymore).

[Akaricchi]

Some of the files (mostly large UASTC textures) are stored pre-compressed in the repo, and I would like to embed them into the zip file, without re-compressing them, and not just storing them in PLAIN mode in a .zst container. E.g. if I put a pre-compressed foobar.basis.zst into stuff.zip, extracting stuff.zip should yield an uncompressed foobar.basis file. I couldn't find a way to do this "natively" through the zipfile module, so that's what write_zst_file‎ does. It unfortunately still has to decompress the file to compute crc32 for the ZipInfo header, hence my reliance on ZstdDecompressor. Let me know if there's a better way.

I believe this hack should already be compatible with ZstdDecompressor from backports.zstd though, and it can be trivially adapted if it's not. Nothing to worry about here.

[Akaricchi]

There was also issue #3 that I forgot about. The python 3.14 zipfile module also sets that constant to 63 currently. I personally don't care about WinZip being unable to extract Taisei resource packs, but I guess someone did care enough to bring up the issue, and changing it to 20 doesn't have any negative effects as far as I know. Probably something to discuss within the Python project itself though.

[Rogdham]

if python is actually built with zstd compreession support

I thought about this some more, and I tend to believe that CPython should be shipped with zstd support by distributions. If not a hard dependency when installing CPython, it should be available after installing libzstd package.

To illustrate, I tested some distributions already shipping python3.14 in their repositories. It seems that zstd support will be out of the box: they all chose to put libzstd as a dependency of their cpython package, and also libzstd is already dependency of their package managers.

Distribution	Version	zstd support	Notes
Debian	Unstable	Yes	libzstd1 is a dependency of dpkg and libpython3.14-stdlib, so always installed
Ubuntu	25.10	Yes	libzstd1 is a dependency of dpkg and libpython3.14-stdlib, so always installed
Fedora	42	Yes	libzstd is a dependency of rpm and python3.14-libs, so always installed
openSUSE	Tumbleweed	Yes	libzstd1 is a dependency of rpm and python314-base, so always installed

unfortunately this is currently not the case for some distributions, such as openSUSE's

That was a bug in openSUSE packaging, which has just been fixed.

If you found other distributions missing support, please report the issue to them or feel free to ping me and I will contact them!