Added PEP 484 type hints to the four public methods in CSVFormat (src/tablib/formats/_csv.py).#642
Conversation
…e public functions in src/tablib/formats/_csv.py. Do not modify executable logic, existing comments, or docstrings.
for more information, see https://pre-commit.ci
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #642 +/- ##
=======================================
Coverage 93.14% 93.15%
=======================================
Files 29 29
Lines 3226 3227 +1
=======================================
+ Hits 3005 3006 +1
Misses 221 221 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
We don't currently have type hints in this project or any type checking in the CI. I'm curious why you chose to add type hints to these four methods in particular? |
|
These four are the only public methods on CSVFormat — the rest of the interface is private. The intent was a minimal, non-breaking annotation of exactly what callers interact with, without touching internal logic or docstrings. |
Added PEP 484 type hints to the four public methods in CSVFormat (src/tablib/formats/_csv.py).
Here's a quick look at the newly annotated signatures:
export_stream_set: dataset: Any, kwargs: Any -> StringIO
export_set: dataset: Any, kwargs: Any -> str
import_set: dset: Any, in_stream: TextIO, headers: bool, skip_lines: int, kwargs: Any -> None
detect: stream: TextIO, delimiter: Optional[str] -> bool
I made sure to leave the underlying logic and docstrings completely alone—this is strictly a typing update. Full disclosure, I let an automated tool called Symbiote handle the heavy lifting for this. It maps the import graph and drops in the annotations, which honestly saves a ton of tedious grunt work without stepping on the actual executable code.
I'd love to hear your thoughts on this. Let me know if these types look right to you, or if you think we should tighten up any of those Any annotations before merging!