fix(deps): update rust crate pyo3 to 0.28.2

[dimastbk]

Summary by CodeRabbit

• Chores

  • Upgraded PyO3 to 0.28.2 and updated related build/source references.
  • Relaxed dev dependency for pandas[excel] to allow 2.2 and later.
  • Expanded CI matrix to include additional Python interpreter versions.

• Improvements

  • Several Python-exposed types now support direct construction from Python objects, improving interoperability.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Bump PyO3 deps to 0.28.2 and switch pyo3-file git source; relax dev pandas[excel] constraint to >=2.2; remove explicit gil_used = false from the PyO3 module attribute; add from_py_object support to several PyO3-exposed types; add Python versions to CI matrix.

Changes

Cohort / File(s)	Summary
Cargo dependency updates Cargo.toml	Bumped pyo3 0.27.1 → 0.28.2 and pyo3-build-config (build-dependencies) to 0.28.2; switched pyo3-file git source from https://github.com/omerbenamram/pyo3-file.git (rev 92e0f5...) to https://github.com/dimastbk/pyo3-file.git (rev b0a5b26...).
Dev dependency relaxation pyproject.toml	Changed pandas[excel] dev constraint from ~=3.0 to >=2.2, widening allowed versions while keeping the [excel] extra.
PyO3 module attribute src/lib.rs	Replaced #[pymodule(gil_used = false)] with #[pymodule]. No other functional changes reported in this file.
PyO3 type conversion additions src/types/sheet.rs, src/types/table.rs	Added from_py_object to PyO3 annotations: SheetTypeEnum and SheetVisibleEnum (#[pyclass(eq, eq_int, from_py_object)]), SheetMetadata (#[pyclass(from_py_object)]), and CalamineTable (#[pyclass(from_py_object)]), enabling construction from Python objects.
CI matrix update .github/workflows/CI.yml	Added additional Python interpreter entries for the Windows x86_64 build matrix (includes 3.13t and 3.14t alongside existing interpreters).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 I hopped from crate to crate with glee,
Tweaked pyo3 to twenty‑eight‑two, swift and spry,
Pandas loosened its bounds, CI grew new shoes,
GIL stepped back, types now learn from Python too—
A tiny rabbit cheers the binding revue.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix(deps): update rust crate pyo3 to 0.28.2' accurately describes the primary change in the pull request, which is the pyo3 dependency update from 0.27.1 to 0.28.2 across multiple files.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch pyo3-0.28

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

pyproject.toml (1)

25-25: Consider adding an upper bound to the pandas[excel] dev constraint.

>=2.2 has no ceiling, so a future pandas major release that breaks test helpers could cause silent CI failures. A tighter spec like >=2.2,<4 would still cover the intended range while guarding against surprise breakage.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@pyproject.toml` at line 25, The dev dependency "pandas[excel]>=2.2" has no
upper bound; update the pyproject.toml dev dependency to pin an upper limit (for
example change "pandas[excel]>=2.2" to "pandas[excel]>=2.2,<4") to prevent
accidental breaks from future major pandas releases while still allowing
patch/minor upgrades.

Cargo.toml (1)

18-18: Pinned to author's own pyo3-file fork — document the upstream migration plan.

Switching from omerbenamram/pyo3-file to dimastbk/pyo3-file is a pragmatic workaround while upstream catches up to PyO3 0.28, but the pinned git dependency has a few downsides:

• Automated dependency tools (Renovate, Dependabot) cannot track or bump it.
• Security patches from upstream are not automatically inherited.

Consider opening a tracking issue to flip back to the upstream crate once it gains PyO3 0.28 compatibility.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Cargo.toml` at line 18, The Cargo.toml currently pins a git dependency to
dimastbk/pyo3-file (the line with pyo3-file = { git = "...", rev = "b0a5b26..."
}) which should be tracked and planned to revert to the upstream
omerbenamram/pyo3-file once it supports PyO3 0.28; add a short TODO comment near
that dependency in Cargo.toml mentioning the upstream repository and target
(omerbenamram/pyo3-file) and reference creating a tracking issue in our repo
(open an issue titled e.g. "Revert pyo3-file to upstream when PyO3 0.28
compatible") that lists the current rev and the condition for flipping back,
then add the new issue number or link to the Cargo.toml comment so automated
tools and future maintainers can find the migration plan.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@Cargo.toml`:
- Line 18: The Cargo.toml currently pins a git dependency to dimastbk/pyo3-file
(the line with pyo3-file = { git = "...", rev = "b0a5b26..." }) which should be
tracked and planned to revert to the upstream omerbenamram/pyo3-file once it
supports PyO3 0.28; add a short TODO comment near that dependency in Cargo.toml
mentioning the upstream repository and target (omerbenamram/pyo3-file) and
reference creating a tracking issue in our repo (open an issue titled e.g.
"Revert pyo3-file to upstream when PyO3 0.28 compatible") that lists the current
rev and the condition for flipping back, then add the new issue number or link
to the Cargo.toml comment so automated tools and future maintainers can find the
migration plan.

In `@pyproject.toml`:
- Line 25: The dev dependency "pandas[excel]>=2.2" has no upper bound; update
the pyproject.toml dev dependency to pin an upper limit (for example change
"pandas[excel]>=2.2" to "pandas[excel]>=2.2,<4") to prevent accidental breaks
from future major pandas releases while still allowing patch/minor upgrades.