Declare dbf, not csv, as the DBF format's file extension - #677
Open
MohammedAlkindi wants to merge 1 commit into
Open
Declare dbf, not csv, as the DBF format's file extension#677MohammedAlkindi wants to merge 1 commit into
MohammedAlkindi wants to merge 1 commit into
Conversation
DBFFormat.extensions has read ('csv',) since the class-based format
refactor in f1046cd, where it was copy-pasted from CSVFormat and never
corrected. Nothing inside tablib reads .extensions, so the test suite
never noticed, but the attribute is public format metadata that
downstream consumers depend on.
django-import-export is the concrete case: TablibFormat.get_extension()
returns self.get_format().extensions[0], and get_export_filename()
interpolates that into the filename the Django admin Export button
serves. Measured against django-import-export 4.4.1 on Django 6.1, a
DBF export downloaded as Invoice-2026-08-17.csv even though its leading
bytes were a DBF header and tablib.detect_format correctly reported
dbf. With this change the same export is named Invoice-2026-08-17.dbf.
Adds a regression test to DBFTests. It is the first test in the suite
to assert on a format's extensions attribute, so the mismatch cannot
silently return.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DBFFormat.extensionsis('csv',). It was copied fromCSVFormatin f1046cd when the formats became classes and never corrected. Every other format declares its own, so_json.pyhas('json', 'jsn')and_xlsx.pyhas('xlsx',).Nothing inside tablib reads
.extensions, which is why no test caught it. Downstream does read it. django-import-export'sTablibFormat.get_extension()returnsself.get_format().extensions[0], andget_export_filename()interpolates that into the filename the Django admin Export button serves. With django-import-export 4.4.1 and Django 6.1 a DBF export downloads asInvoice-2026-08-17.csvwhile its first bytes are\x03~\x08\x11andtablib.detect_formatcorrectly reportsdbf. After the change it isInvoice-2026-08-17.dbf.The test goes in the existing
DBFTestsclass besidetest_dbf_format_detect. On master it fails withTuples differ: ('dbf',) != ('csv',).Full suite on Python 3.13, 181 passed before and 182 after. Two tests fail identically either side and neither is touched here:
test_auto_format_detect, which needs a pandas DLL my machine blocks, andtest_getDate_datetime_timestamp, a timezone failure that is #675.