FIX: accept memoryview in Binary()

[Gaurav Sharma (bewithgaurav)]

Work Item / Issue Reference

GitHub Issue: #739

---

Summary

Binary() rejected memoryview with a TypeError, so any DB-API caller that
passes a buffer-protocol value failed. Django's BinaryField hands the driver a
memoryview, which broke BinaryField writes and the serializer roundtrips.
Accept memoryview via tobytes(), matching pyodbc and the DB-API convention.

[Copilot]

🟡 Changes recommended

The runtime API change isn’t reflected in the public type stubs (mssql_python/mssql_python.pyi), which will cause type-checking inconsistencies for downstream users.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR fixes DB-API compatibility for binary parameters by allowing mssql_python.Binary() to accept memoryview, which is commonly passed by Django’s BinaryField (GH-739), aligning behavior with pyodbc and typical buffer-protocol usage.

Changes:

• Extend Binary() to accept memoryview via tobytes(), and update the error message and docstring accordingly.
• Add unit coverage for memoryview inputs and update existing error-message assertions in type tests.

File summaries

File	Description
mssql_python/type.py	Accepts memoryview in Binary() and updates docs/error message to reflect the expanded supported input types.
tests/test_002_types.py	Adds a memoryview test case for Binary() and updates TypeError message expectations for unsupported types.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

📊 Code Coverage Report

🔥 Diff Coverage 100%

🎯 Overall Coverage 82%

📈 Total Lines Covered: 7804 out of 9478 📁 Project: mssql-python

---

Diff Coverage

Diff: main...HEAD, staged and unstaged changes

• mssql_python/type.py (100%)

Summary

• Total: 4 lines
• Missing: 0 lines
• Coverage: 100%

---

📋 Files Needing Attention

📉 Files with overall lowest coverage (click to expand)

mssql_python.pybind.logger_bridge.cpp: 58.9%
mssql_python.pybind.ddbc_bindings.h: 61.5%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 75.5%
mssql_python.__init__.py: 77.6%
mssql_python.row.py: 77.6%
mssql_python.pybind.connection.connection_pool.cpp: 81.6%
mssql_python.pybind.connection.connection.cpp: 84.4%
mssql_python.logging.py: 85.5%
mssql_python.connection.py: 85.9%

---

🔗 Quick Links

⚙️ Build Summary	📋 Coverage Details
View Azure DevOps Build	Browse Full Coverage Report

[Sumit Sarabhai (sumitmsft)]

Reviewed the PR for correctness, security, reliability, performance, test coverage, repository conventions, and applicable architecture and design specifications. No actionable issues were identified. The implementation is consistent with repository standards and the applicable approved design requirements.

Details

• Binary() normalizes memoryview to an exact bytes via .tobytes(), preserving the existing bytes return contract. This keeps the downstream binding path unchanged, since the binder already maps bytes to SQL_VARBINARY/SQL_C_BINARY (including large-value streaming).
• .tobytes() produces an owned copy in logical C order, so non-contiguous, bytearray-backed, and empty memoryviews all round-trip correctly with no aliasing/lifetime concern.
• Accepting memoryview aligns with pyodbc's acceptance of buffer-protocol values (pyodbc materializes to bytearray; this driver keeps its bytes contract) and resolves GH-739 (Django BinaryField hands the driver a memoryview).
• Runtime signature and the PEP 561 .pyi stub are kept in sync; a focused regression test covers memoryview inputs and the updated error message; Black passes.

Recommendation: Approve