Bit accepts a zero-length value from bytes or binary data, but cannot reconstruct that value from its own to_text() output. Direct construction from an empty string or list fails the same way.

Reproduced on current master at 8cef6e4e867b8d07971da1a3d6170fb6e75e3c40 (package version 0.5.1), with Python 3.13.16:

from struct import pack
from pgvector import Bit

bit = Bit(b"")
assert bit.to_list() == []
assert bit.to_text() == ""
assert bit.to_binary() == pack(">i", 0)
assert Bit.from_binary(bit.to_binary()) == bit

Bit.from_text(bit.to_text())
# ValueError: invalid literal for int() with base 2: ''

# These also raise the same ValueError:
# Bit("")
# Bit([])

The shared string/list constructor reaches int(value, 2) with value == "". This makes text round trips inconsistent with the already accepted empty bytes/binary representation. I would expect the empty text/list inputs to preserve that same zero-length value, rather than represent a one-bit zero or raise an integer-parsing error.

Nonempty controls at lengths 1, 7, 8 and 9 preserve their exact text and binary representations. Bit(b"\x00") remains eight zero bits, distinct from the empty value, and invalid strings such as "0b1", "1_0" and "201" are still rejected. This is separate from the invalid-string validation fixed in #161 and the SQLAlchemy input adaptation proposed in #137.

This report concerns the public Bit conversion API only. The reproduction and controls were executed directly against the cited source using the Python standard library; no NumPy or PostgreSQL round trip is claimed. The repository pytest suite could not start because pytest was unavailable, and dependency restoration failed over verified HTTPS, so I am not submitting a code fix as validated.

Prepared with AI assistance; no human review is claimed.