oconnor663 / blake3-py Goto Github PK

View Code? Open in Web Editor NEW

139.0 139.0 12.0 301 KB

Python bindings for the BLAKE3 cryptographic hash function

License: Other

Python 43.98% Rust 32.57% C 23.45%

blake3-py's People

Contributors

Stargazers

Watchers

Forkers

edggge shrids maartenbreddels xkortex topboy89 clintonkildepstein mgorny arpitjain799 oconnor663-travel kmichel-aiven mostawesomedude jm4rc05 mpranav38

blake3-py's Issues

C-based pypi package

It would be cool to have a C-based pypi package for the blake3 bindings.

I've read the ticket on the Python issue tracker about hashlib inclusion, but that was closed / rejected (for now) - what a pity.

I guess there are some projects out there (like borgbackup, see borgbackup/borg#45 (comment) ) that would like to add blake3, but not introduce a dependency on the rust toolchain. The latter might be no big issue if you target modern linux dists, but if you try to support a lot of platforms, this at least creates a lot of uncertainties (that block adoption) if not real issues (if one adopts and then stumbles into them).

Not supporting internal multithreading is no issue in our case because if we implement MT, we need to do that on a higher level anyway. The GIL should be freed though while computing a hash, so it doesn't block other stuff for no reason.

Parent module of blake3.blake3.blake3 is builtins

I guess it comes from your build system (maturin IIUC?), but blake3.blake3.blake3 (or the shorter blake3.blake3) says its parent module is builtins:

>>> from blake3 import blake3
>>> blake3.__module__
'builtins'

It's problematic because there's no blake3 object importable from builtins.
It makes it impossible to inspect the object without special-casing it. For reference: mkdocstrings/mkdocstrings#451 (comment)

Do you know if there's a way to compile the project so that its objects correctly report their parent modules, for example blake3.blake3 (and not builtins)?

allow the key parameter to be a bytearray

The way we define the bindings, the key is required to be a bytes object, and it can't be e.g. a bytearray. This is an unnecessary restriction. We should probably refactor the buffer API code so that we can call it twice, and then treat the key the same way we treat the input bytes.

C implementation fails to compile with GCC 14

When building with GCC 14 (that's more strict than previous versions), the package fails to build:

$ python3.12 setup.py build
including x86-64 Unix assembly
running build
running build_ext
building 'blake3' extension
creating build/temp.linux-x86_64-cpython-312
creating build/temp.linux-x86_64-cpython-312/vendor
x86_64-pc-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -fPIC -DSETUP_PY_VERSION=\"0.0.1\" "-DSETUP_PY_DESCRIPTION=\"experimental bindings for the BLAKE3 C implementation, API-compatible with the Rust-based blake3 module\"" -Ivendor -I/usr/include/python3.12 -c blake3module.c -o build/temp.linux-x86_64-cpython-312/blake3module.o
blake3module.c: In function ‘Blake3_update’:
blake3module.c:220:7: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from incompatible pointer type ‘Blake3Object *’ [-Wincompatible-pointer-types]
  220 |   ret = self;
      |       ^
blake3module.c: In function ‘Blake3_update_mmap’:
blake3module.c:275:7: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from incompatible pointer type ‘Blake3Object *’ [-Wincompatible-pointer-types]
  275 |   ret = self;
      |       ^
blake3module.c: At top level:
blake3module.c:350:21: error: initialization of ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} from incompatible pointer type ‘PyObject * (*)(PyObject *, PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *, struct _object *)’} [-Wincompatible-pointer-types]
  350 |     {"update_mmap", (PyCFunctionWithKeywords)Blake3_update_mmap,
      |                     ^
blake3module.c:350:21: note: (near initialization for ‘Blake3_methods[1].ml_meth’)
blake3module.c:352:16: error: initialization of ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} from incompatible pointer type ‘PyObject * (*)(PyObject *, PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *, struct _object *)’} [-Wincompatible-pointer-types]
  352 |     {"digest", (PyCFunctionWithKeywords)Blake3_digest,
      |                ^
blake3module.c:352:16: note: (near initialization for ‘Blake3_methods[2].ml_meth’)
blake3module.c:354:19: error: initialization of ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} from incompatible pointer type ‘PyObject * (*)(PyObject *, PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *, struct _object *)’} [-Wincompatible-pointer-types]
  354 |     {"hexdigest", (PyCFunctionWithKeywords)Blake3_hexdigest,
      |                   ^
blake3module.c:354:19: note: (near initialization for ‘Blake3_methods[3].ml_meth’)
error: command '/usr/bin/x86_64-pc-linux-gnu-gcc' failed with exit code 1

Reproduced with Python 3.12.4, blake3-py 40c8bd9.

Add pypy to CI

~~After PyO3/maturin#596 ships.~~ That fix has shipped.

fix CI for 32-bit Windows

The upgrade to PyO3 0.12 made PYO3_CROSS_INCLUDE_DIR mandatory for that target, but I'm not sure yet how to set it.

stop pinning nightly-2020-02-05

We're currently pinning a specific nightly version in the rust-toolchain file. We should go back to regular nightly (as long as PyO3 requires it) as soon as these issues are resolved:

BLAKE3-team/BLAKE3#56
BLAKE3-team/BLAKE3#57
rust-lang/rust#68905

Add type stubs for blake3 library.

Below is a draft type stub for the blake3 module. I found this issue in the Maturin repo suggesting that adding type stubs to the project should be easy: PyO3/maturin#618

One detail to double-check is that the py.typed file gets generated; this signals that the installed library also includes type stubs. See https://github.com/PyO3/maturin/blob/main/test-crates/pyo3-pure/check_installed/check_installed.py.

The type definitions below are derived from the hashlib definition in typeshed and the interactive help in python. I inlined the definition of ReadableBuffer.

Forgive me for throwing this over the wall instead of creating a proper PR. I am not a rust programmer and do not have anything set up. I am however happy to test and follow up on a library release that includes type stubs.

Thanks for creating the library - I'm curious to test blake3!

from array import array
from ctypes import _CData
from mmap import mmap
from typing import Any, Optional, TypeVar, Union


ReadableBuffer = Union[bytes, bytearray, memoryview, array[Any], mmap, _CData]
#^ Derived from typeshed/stdlib/typeshed/__init__.py.

_Self = TypeVar("_Self")


class blake3:

  def __init__(self, data:ReadableBuffer=..., key:Optional[ReadableBuffer]=None,
    derive_key_context:Optional[str]=None, multithreading:bool=False) -> None: ...

  @property
  def block_size(self) -> int: ...

  @property
  def digest_size(self) -> int: ...

  @property
  def key_size(self) -> int: ...

  @property
  def name(self) -> str: ...

  def copy(self: _Self) -> _Self: ...

  def digest(self) -> bytes: ...

  def hexdigest(self) -> str: ...

  def update(self, __data: ReadableBuffer, *, multithreading=False) -> None: ...

binary wheel for apple silicon (M1 cpu)

... would be nice to have.

Feature: accept memoryview besides bytes

Hi,

thanks for this library, I was looking for something like blake3, so when I found it and found out there was a Python binding, that made me very happy :).

I was wondering if it would be simple to support memoryview instead of bytes. You can get a memoryview on a bytes object, so that would allow for less memory copies if I am not mistaken. Having a memoryview, and converting it to a bytes object (mv.tobytes()) does seem to do a memory copy.

Regards,

Maarten

[Enhancement] - More bytes for random_key.

It'd be nice if I/we could use more than just 32 bytes for the creation of a random key.

I'm not sure if it is possible but I'd like to chose as many bytes as I want.

an upstream platform detection bug is causing test failures with 32-bit Python

See PyO3/pyo3#830.

Recommendations for performance

I'm making a hash of all files in a directory as follows. The total size might be GBs. Individual files are mostly hundreds of KBs, but can be MBs or GBs in some cases (in which case I don't want to read them entirely into memory).

hasher = blake3()
for root, dirs, files in os.walk(directory):
    dirs.sort()
    for file in sorted(files):
        with open(os.path.join(root, file), 'rb') as f:
            for chunk in iter(partial(f.read, 8192), b''):
                hasher.update(chunk)
return hasher.hexdigest()

I'm wondering:

What are the recommendation around chunk size? I'm not looking for optimal performance, but I also don't want to choose a chunk size that is obviously worse to someone who knows blake3 better.

The readme has "As a rule of thumb, don't use multithreading for inputs shorter than 1 MB", so I'm also wondering if I should read in a large-ish chunk size and then use hasher.update(chunk, multithreading=True) – or if it's faster to read small chunks without multithreading. There might be an obvious answer...

Please cut new release of blake3 to fix maturin build error

Could you please cut a new release that includes the this commit 87b457f

Thanks!

Error:

Collecting blake3
  Downloading blake3-0.2.0.tar.gz (33 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... error
    ERROR: Command errored out with exit status 1:
     command: /root/.cache/pypoetry/virtualenvs/sanic-pIZXgjO4-py3.10/bin/python /root/.cache/pypoetry/virtualenvs/sanic-pIZXgjO4-py3.10/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmp8b9h7wi_
         cwd: /tmp/pip-install-7r5nrcxv/blake3_55702c73c4e04459aeb27d52bbbb201f
    Complete output (7 lines):
    Checking for Rust toolchain....
    Running `maturin pep517 write-dist-info --metadata-directory /tmp/pip-modern-metadata-aduv54rk --interpreter /root/.cache/pypoetry/virtualenvs/sanic-pIZXgjO4-py3.10/bin/python`
    ⚠️  Warning: Please use maturin in pyproject.toml with a version constraint, e.g. `requires = ["maturin>=0.11,<0.12"]`. This will become an error.
    💥 maturin failed
      Caused by: Cargo metadata failed. Does your crate compile with `cargo build`?
      Caused by: `cargo metadata` exited with an error:     Updating crates.io index
    Error running maturin: Command '['maturin', 'pep517', 'write-dist-info', '--metadata-directory', '/tmp/pip-modern-metadata-aduv54rk', '--interpreter', '/root/.cache/pypoetry/virtualenvs/sanic-pIZXgjO4-py3.10/bin/python']' returned non-zero exit status 1.
    ----------------------------------------
WARNING: Discarding https://files.pythonhosted.org/packages/c8/dc/40d740998936be074666acaf2d1f7c90959898272bf587377f1f65c86b7b/blake3-0.2.0.tar.gz#sha256=91794f3335062ff484aaef1ff028276c904b1eca0cccfea18e081c25b5f2c7d0 (from https://pypi.org/simple/blake3/). Command errored out with exit status 1: /root/.cache/pypoetry/virtualenvs/sanic-pIZXgjO4-py3.10/bin/python /root/.cache/pypoetry/virtualenvs/sanic-pIZXgjO4-py3.10/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmp8b9h7wi_ Check the logs for full command output.

conda-forge package

Have you considered making a conda-forge package:
https://conda-forge.org/
I'm happy to help set this up. Basically it's following this:
https://conda-forge.org/#add_recipe

blacke3's method has 'multithreading' param missing since blake3 v0.3

Bug description

# v0.2.1: Creates a blake3 object
blake3(value.encode("utf-8"), multithreading=False)

# v0.3.0: Fails to create a blake3 object
blake3(value.encode("utf-8"), multithreading=False)
# Exception raised: blake3.__new__() got an unexpected keyword argument 'multithreading'

How to reproduce:

Install blake3 v0.3
Run sample code

Wheels for Python 3.11 and PyPy

It would be nice to have wheels for Python 3.11 and PyPy (3.7 and 3.8), so as to not need cargo when installing blake3 in such environments.

This is a mere request, not a demand nor anything. Thanks for the good work here!.

64 byte hash with blake3

How do I use this library to create a 64 byte (or any other size) hash with blake3 or am I always limited to 32 bytes. I thought Blake3 supported configurable hash sizes like blake2b.

figure out how to upload binary wheels from CI builds

Particularly both 32-bit and 64-bit for Windows.

Precompiled wheel package for CPython3.12

From the current latest version 0.3.3, it only supports python3.11. It was released in December 2022, but now python3.12 has been released, which causes pip installation to be compiled from source code.

As we all know, blake3 must install the rust runtime in this case, which is quite troublesome for many things, especially in docker build, so it is best to have a pre-built wheel package for CPython3.12.

c_impl: usedforsecurity=True overflows and damages max_threads

After making it build, i thought i better run the tests (on Apple M1):

_________________________________________________________ test_usedforsecurity_ignored _________________________________________________________

    def test_usedforsecurity_ignored():
>       blake3(usedforsecurity=True)
E       ValueError: invalid value for max_threads

tests/test_blake3.py:360: ValueError
=========================================================== short test summary info ============================================================
FAILED tests/test_blake3.py::test_usedforsecurity_ignored - ValueError: invalid value for max_threads

[feature request] copy() method and `name` attribute

I'd like to implement a copy() method and a name attribute (which just returns 'blake3'). This would bring its interface in line with the other hashlib functions. I think this might do it, but I am insufficiently rusty 🦀 , so I was hoping you could take a look before I PR it.

This failed and I can't figure out why.

        #[getter]
        fn name(
            &mut self,
            py: Python,
        ) -> PyResult<PyString> {
            Ok(PyString::from_str("blake3"))
        }

     Compiling blake3 v0.1.7 (/private/var/folders/wp/kcxqg3tx3sg5cyl2sq9hw6qh0000gn/T/pip-req-build-t1pjouit)
  error: could not compile `blake3`.

  To learn more, run the command again with --verbose.
  💥 maturin failed
    Caused by: Failed to build a native library through cargo
    Caused by: Cargo build finished with "exit code: 101": `cargo rustc --message-format json --manifest-path Cargo.toml --lib --release -- -C link-arg=-undefined -C link-arg=dynamic_lookup`
  Running `maturin pep517 build-wheel -i python`
  Error: Command '['maturin', 'pep517', 'build-wheel', '-i', 'python']' returned non-zero exit status 1.
  ----------------------------------------
  ERROR: Failed building wheel for blake3
Failed to build blake3
ERROR: Could not build wheels for blake3 which use PEP 517 and cannot be installed directly

This seems to work:

        /// Return a copy of a Blake3Hasher object.
        /// I have no idea if this is threadsafe
        fn copy(
            &mut self,
            py: Python,
        ) -> PyResult<Blake3Hasher> {
            Ok( Blake3Hasher { rust_hasher: self.rust_hasher.clone() })
        }

In [1]: import blake3

In [2]: b1 = blake3.blake3(b'foo')

In [3]: b1.hexdigest()
Out[3]: '04e0bb39f30b1a3feb89f536c93be15055482df748674b00d26e5a75777702e9'

In [4]: b2 = b1.copy()

In [5]: b1.update(b'bar')

In [6]: b1.hexdigest()
Out[6]: 'aa51dcd43d5c6c5203ee16906fd6b35db298b9b2e1de3fce81811d4806b76b7d'

In [7]: b2.hexdigest()
Out[7]: '04e0bb39f30b1a3feb89f536c93be15055482df748674b00d26e5a75777702e9'

In [8]: blake3.blake3(b'foobar').hexdigest()
Out[8]: 'aa51dcd43d5c6c5203ee16906fd6b35db298b9b2e1de3fce81811d4806b76b7d'

Thanks,

Linux wheel for aarch64 and armv7 architecture ?

I've seen that you've provided lots of wheel package but could you please provide linux wheel for aarch64 and armv7 architecture ?

enable the "c" feature by default

This is currently blocked on rust-lang/rust#68905.

"undefined symbol: PyUnicode_AsUTF8AndSize" runtime linker error under PyPy 7.3.5

blake3-py works with cpython 3.9, but it does not work with PyPy 7.3.5.

============================================================================================ test session starts =============================================================================================
platform linux -- Python 3.7.10[pypy-7.3.5-final], pytest-6.2.4, py-1.10.0, pluggy-0.13.1 -- /home/amirouche/.cache/pypoetry/virtualenvs/asyncio-foundationdb-MsScwi0I-py3.7/bin/pypy3
cachedir: .pytest_cache
rootdir: /home/amirouche/src/python/found
plugins: cov-2.12.1, pylama-7.7.1, asyncio-0.15.1
collected 0 items / 1 error

=================================================================================================== ERRORS ===================================================================================================
_________________________________________________________________________________________ ERROR collecting tests.py __________________________________________________________________________________________
ImportError while importing test module '/home/amirouche/src/python/found/tests.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../../../.cache/pypoetry/virtualenvs/asyncio-foundationdb-MsScwi0I-py3.7/site-packages/_pytest/python.py:578: in _importtestmodule
    mod = import_path(self.fspath, mode=importmode)
../../../.cache/pypoetry/virtualenvs/asyncio-foundationdb-MsScwi0I-py3.7/site-packages/_pytest/pathlib.py:524: in import_path
    importlib.import_module(module_name)
/usr/lib/pypy3/lib-python/3/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1015: in _gcd_import
    ???
<frozen importlib._bootstrap>:992: in _find_and_load
    ???
<frozen importlib._bootstrap>:976: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:686: in _load_unlocked
    ???
../../../.cache/pypoetry/virtualenvs/asyncio-foundationdb-MsScwi0I-py3.7/site-packages/_pytest/assertion/rewrite.py:170: in exec_module
    exec(co, module.__dict__)
tests.py:11: in <module>
    from found import bstore
found/bstore.py:24: in <module>
    from blake3 import blake3
../../../.cache/pypoetry/virtualenvs/asyncio-foundationdb-MsScwi0I-py3.7/site-packages/blake3/__init__.py:1: in <module>
    from .blake3 import *
E   ImportError: /home/amirouche/.cache/pypoetry/virtualenvs/asyncio-foundationdb-MsScwi0I-py3.7/site-packages/blake3/blake3.pypy37-pp73-x86_64-linux-gnu.so: undefined symbol: PyUnicode_AsUTF8AndSize

please upload python3.10 x86-64 wheels to pypi

Is this library also available for nodejs ?

packaging build is broken by new CET code

Here's what comes out of the Maturin container now:

[root@35576b33609c c]# gcc -O3 -o example example.c blake3.c blake3_dispatch.c blake3_portable.c blake3_sse41_x86-64_unix.S blake3_avx2_x86-64_unix.S blake3_avx512_x86-64_unix.S -std=c99
blake3_sse41_x86-64_unix.S:1:58: error: missing binary operator before token "("
 #if defined(__ELF__) && defined(__CET__) && __has_include(<cet.h>)
                                                          ^
blake3_avx2_x86-64_unix.S:1:58: error: missing binary operator before token "("
 #if defined(__ELF__) && defined(__CET__) && __has_include(<cet.h>)
                                                          ^
blake3_avx512_x86-64_unix.S:1:58: error: missing binary operator before token "("
 #if defined(__ELF__) && defined(__CET__) && __has_include(<cet.h>)
                                                          ^

[root@35576b33609c c]# gcc --version
gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Apple Silicon (M1 CPU) support?

This refers to the stuff in c_impl/:

Didn't get it to work on macOS / M1.

  Preparing metadata (setup.py) ... done
Installing collected packages: blake3-experimental-c
  Running setup.py develop for blake3-experimental-c
    Running command /Users/tw/w/blake3-py-env/bin/python3.9 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/tw/w/blake3-py/c_impl/setup.py'"'"'; __file__='"'"'/Users/tw/w/blake3-py/c_impl/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps
    portable code only
    running develop
    /Users/tw/w/blake3-py-env/lib/python3.9/site-packages/setuptools/command/easy_install.py:156: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
      warnings.warn(
    /Users/tw/w/blake3-py-env/lib/python3.9/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
      warnings.warn(
    running egg_info
    creating blake3_experimental_c.egg-info
    writing manifest file 'blake3_experimental_c.egg-info/SOURCES.txt'
    writing manifest file 'blake3_experimental_c.egg-info/SOURCES.txt'
    running build_ext
    creating build
    creating build/temp.macosx-12-arm64-3.9
    creating build/temp.macosx-12-arm64-3.9/vendor
    clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DSETUP_PY_VERSION=\"0.0.1\" "-DSETUP_PY_DESCRIPTION=\"experimental bindings for the BLAKE3 C implementation, API-compatible with the Rust-based blake3 module\"" -Ivendor -I/Users/tw/w/blake3-py-env/include -I/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c blake3module.c -o build/temp.macosx-12-arm64-3.9/blake3module.o
    clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DSETUP_PY_VERSION=\"0.0.1\" "-DSETUP_PY_DESCRIPTION=\"experimental bindings for the BLAKE3 C implementation, API-compatible with the Rust-based blake3 module\"" -Ivendor -I/Users/tw/w/blake3-py-env/include -I/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c vendor/blake3.c -o build/temp.macosx-12-arm64-3.9/vendor/blake3.o
    clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DSETUP_PY_VERSION=\"0.0.1\" "-DSETUP_PY_DESCRIPTION=\"experimental bindings for the BLAKE3 C implementation, API-compatible with the Rust-based blake3 module\"" -Ivendor -I/Users/tw/w/blake3-py-env/include -I/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c vendor/blake3_dispatch.c -o build/temp.macosx-12-arm64-3.9/vendor/blake3_dispatch.o
    vendor/blake3_dispatch.c:241:3: warning: code will never be executed [-Wunreachable-code]
      blake3_hash_many_portable(inputs, num_inputs, blocks, key, counter,
      ^~~~~~~~~~~~~~~~~~~~~~~~~
    vendor/blake3_dispatch.c:85:5: warning: unused function 'get_cpu_features' [-Wunused-function]
        get_cpu_features() {
        ^
    2 warnings generated.
    clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DSETUP_PY_VERSION=\"0.0.1\" "-DSETUP_PY_DESCRIPTION=\"experimental bindings for the BLAKE3 C implementation, API-compatible with the Rust-based blake3 module\"" -Ivendor -I/Users/tw/w/blake3-py-env/include -I/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c vendor/blake3_portable.c -o build/temp.macosx-12-arm64-3.9/vendor/blake3_portable.o
    creating build/lib.macosx-12-arm64-3.9
    clang -bundle -undefined dynamic_lookup -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk build/temp.macosx-12-arm64-3.9/blake3module.o build/temp.macosx-12-arm64-3.9/vendor/blake3.o build/temp.macosx-12-arm64-3.9/vendor/blake3_dispatch.o build/temp.macosx-12-arm64-3.9/vendor/blake3_portable.o -o build/lib.macosx-12-arm64-3.9/blake3.cpython-39-darwin.so
Successfully installed blake3-experimental-c-0.0.1

(blake3-py-env) tw@mba2020 c_impl % python3
Python 3.9.10 (main, Jan 15 2022, 11:40:53) 
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import blake3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/Users/tw/w/blake3-py/c_impl/blake3.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace '_blake3_hash_many_neon'

todo: upgrade to pyo3 0.12

manylinux wheel doesn't work on Centos 7 / Python 3.8.2

[root@vh0 ~]# /opt/python/3.8.2/bin/python -m venv /opt/util/py38
[root@vh0 ~]# source /opt/util/py38/bin/activate
(py38) [root@vh0 ~]# pip install blake3
Collecting blake3
  Using cached https://files.pythonhosted.org/packages/d7/d9/4740acd52573498efa4beddb98b3e4ecfe6f4a8c425e8c618fb2092cd802/blake3-0.1.4-cp38-cp38-manylinux1_x86_64.whl
Installing collected packages: blake3
Successfully installed blake3-0.1.4
(py38) [root@vh0 ~]# python
Python 3.8.2 (default, Feb 26 2020, 08:29:54) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import blake3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /opt/util/py38/lib/python3.8/site-packages/blake3.cpython-38-x86_64-linux-gnu.so)
>>> exit()
(py38) [root@vh0 ~]# cat /etc/system-release
CentOS Linux release 7.7.1908 (Core)

I searched for the error message, which might be similar to PyO3/maturin#47 referenced in ijl/orjson#2 . I could not determine if that is indeed adressed in rust or Pyo3

v1.0 release checklist

The module has been stable for a while now, and it's probably time to give it a 1.0 release. This issue is for tracking any work I should take care of first.

#26
actual docs? :)