-
Notifications
You must be signed in to change notification settings - Fork 436
bugfix: Fix an occasional compatibility issue when using Excel formulas #380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #380 +/- ##
==========================================
+ Coverage 56.55% 57.30% +0.75%
==========================================
Files 24 24
Lines 5526 5528 +2
==========================================
+ Hits 3125 3168 +43
+ Misses 2401 2360 -41 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
What leads you to encounter this? Curious why you're still using .xls files? |
Thanks for asking! Some of our internal systems still produce .xls file. To support a business requirement involving legacy .xls files, I used xlrd.open_workbook to load them. However, certain older files triggered unexpected errors. After investigating the source code, I identified the cause and made a targeted fix. The issue was resolved, so I’m submitting this patch accordingly. |
Okay, if you want this to land, you'll need to add suitable unit tests to cover the code you've added and that demonstrate the problem. |
Ok, I've added a unit test |
What is it that's resulting in that malformed formula? Wouldn't it be better to fix that? |
I’m not entirely sure how this particular malformed formula was created—modern Excel immediately prevents manual entry of such expressions. It may have originated from an older export or another tool outside our control. Since our goal is to parse user-provided workbooks without altering their original data, it would be more user-friendly to handle this scenario gracefully in xlrd rather than requiring users to clean up legacy files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The testing is not sufficient.
What is the result of the change you've made in formula.py? How does this surface in the resulting xlrd objects?
tests/test_invalid_formula.py
Outdated
|
||
class TestInvalidFormula(unittest.TestCase): | ||
def test_evaluate_name_formula_with_invalid_operand(self): | ||
xlrd.open_workbook(from_sample('invalid_formula.xls')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test needs to make assertions.
Please match the style of existing tests and find the best module to add them to.
tests/test_invalid_formula.py
Outdated
xlrd.open_workbook(from_sample('invalid_formula.xls')) | ||
|
||
|
||
if __name__ == '__main__': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't add block like this, run the tests in the existing way, the developer docs cover this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I added the assertions and cleaned up the test style as suggested.
Let me know if there’s anything else — thanks for the review!
Problem
When loading an Excel file with complex formulas, an AttributeError is raised:
argtext = listsep.join(arg.text for arg in stack[-nargs:])
^^^^^^^^
AttributeError: 'int' object has no attribute 'text'
This happens because some invalid formula arguments are pushed to the stack as raw types (e.g., int) instead of wrapped Operand instances.
Solution
Ensure all arguments pushed onto the formula stack are properly wrapped in Operand objects, even when the formula is malformed. This prevents attribute access errors during parsing.