Skip to content

Tags: oconnor663/blake3-py

Tags

0.4.1

Toggle 0.4.1's commit message
version 0.4.1

Changes since 0.4.0:
- `update` and `update_mmap` now return self, so they can be called
  fluently.

0.4.0

Toggle 0.4.0's commit message
version 0.4.0

Changes since 0.3.4:
- Add blake3.update_mmap.

0.3.4

Toggle 0.3.4's commit message
version 0.3.4

Changes since 0.3.3:
- Add type stubs. See blake3.pyi.
- Update PyO3 to v0.20.

0.3.3

Toggle 0.3.3's commit message
version 0.3.3

Changes since 0.3.2:
- Change `blake3.__module__` from "blake3" to "blake3.blake3". This is
  the correct canonical path, related to some Maturin implementation
  details. This is intended to help tooling that relies on canonical
  paths, but most regular callers don't need to worry about this. See
  mkdocstrings/mkdocstrings#451 for an example
  of a tool that needs to know this.
- Update PyO3 to v0.17.

0.3.2

Toggle 0.3.2's commit message
version 0.3.2

Changes since 0.3.1:
- `from blake3 import blake3; blake3.__module__` now correctly returns
  "blake3". Fixes #38.
- Updated Maturin to version 0.14.

0.3.1

Toggle 0.3.1's commit message
version 0.3.1

Changes since 0.3.0:
- The experimental C implementation has been bumped to v0.0.1. Testers
  and reviewers can install this implementation from TestPyPI with:
  `pip install -i https://test.pypi.org/simple/ blake3-experimental-c`
- We now avoid releasing the GIL for short inputs and release the GIL
  for long outputs in addition to long inputs.
- The experimental C implementation now has GIL handling matching the
  Rust implementation.
- Both implementations now contain an internal mutex, to protect the
  state object from data races. However, it's still possible for data
  races to occur in the input buffer. (This is also the case for
  standard hashlib implementations.)

0.3.0

Toggle 0.3.0's commit message
version 0.3.0

Changes since 0.2.1:
- There is now an experimental, API-compatible C implementation of the
  Python `blake3` module in the c_impl/ directory. This a
  proof-of-concept for code that might be submitted to Python's standard
  hashlib module in the future. It probably won't be published on PyPI.
- The `multithreading` keyword arg previously on blake3() and update()
  has been replaced with the `max_threads` keyword arg on blake3() only.
  This accepts any positive integer, or the special value `blake3.AUTO`,
  which is equivalent to the previous behavior. This change helps
  compatiblity with the current C implementation, which ignores
  `max_threads`, and with a hypothetical future C implementation, which
  might want to store a thread pool on the hasher.
- Added the reset() method. This is potentially helpful for reusing
  threading resources, which are currently local to the hasher when
  `max_threads` is greater than 1 and not equal to `blake3.AUTO`.
- Added a `usedforsecurity` keyword arg, for compatibility with hashlib.
  The value is currently ignored.
- Most keyword arguments are now strictly keyword-only, and `data`
  arguments are now strictly positional-only.

0.2.1

Toggle 0.2.1's commit message
version 0.2.1

Changes since 0.2.0:
- The "blake3" crate version has been updated to 1.0.0.
- Binary wheels for Apple Silicon are now built with GitHub releases and
  published to PyPI.

0.2.0

Toggle 0.2.0's commit message
version 0.2.0

Changes since 0.1.8:
- Rename the "context" keyword argument to "derive_key_context" for
  clarity.
- Upgrade PyO3 to 0.14, which raises the minimum supported Python
  version to 3.6.
- The blake3.OUT_LEN and blake3.KEY_LEN module constants have been
  replaced with "digest_size" and "key_size" attributes on the hasher
  object itself. This is more consistent with how the standard hashlib
  module behaves. A "block_size" attribute has also been added.
- Add the blake3.__version__ module constant.
- Add the "neon" Cargo feature, which maps to the "neon" feature of the
  underlying blake3 crate.

0.1.8

Toggle 0.1.8's commit message
version 0.1.8

Changes since 0.1.7:
- The hasher now supports the `copy` method and the `name` attribute,
  matching the conventions of `hashlib`. Added by @xkortex.
- The optional key argument can now be any buffer type, just like the
  `data` argument can. Previously `key` could only be `bytes`.