Gemini xlsx importer fails on long digits about perfi HOT 6 CLOSED

Great point @bayesianmind

Merged your suggestion in b0ff639

from perfi.

Turns out this is a very old long-standing bug in openpyxl and the fix is to use an alternate library or apply a patch: https://stackoverflow.com/questions/13637888/openpyxl-please-do-not-assume-text-as-a-number-when-importing

from perfi.

Thanks for chasing that down, will sit down soon and figure the best way to triage. We already use xlsxwriter since it does a better job on writing our export, could look into pylightxl vs openpyxl for reading I guess? https://www.python-excel.org/

Or it might be easier to add a case to look for scientific notation and just have decimal_from_str handle it. @peloriante

from perfi.

I tried pylightxl and it does the exact same behavior unfortunately.
Both seem to be keeping the precision, so likely the solution here is having decimal_from_str understand scientific notation.

from perfi.

Thanks for this report, @bayesianmind! I made a small change (See fd63f28) to just float the str inside decimal_from_str before we cast to Decimal. I think this will handle parsing out any scientific notation present in the value.

Can you get latest and try again?

from perfi.

Thanks @peloriante!
It would be best to keep precision, especially given how huge some units can be. I tested your patch on my import and was seeing sizable rounding errors, especially for BTC where 1 unit is so expensive.
I put a comment on fd63f28 suggesting a better implementation that preserves all precision.

from perfi.