GenAI lately managed to build confidence with me, only for today to do a 180 and say, paraphrased, "Your issue is caused by X rather than Y. The likely cause is Y".

At least it works for the tar-pit...

morning cabbages, folks

Rant time

Rant #1: I am working on replacing an internal app with Python. I have the output I produce as DataFrame and the target/productive output as a DataFrame. I do a column-by-column comparison, and if I do .fillna("nan") on both, only one of them actually gets filled with the String "nan", the other does not. Even though both columns are type object and contain identical data. Oh, and .fillna("") does actually properly fill both columns, for some reason.

Rant #2: We have an internal library for working for openpyxl because it comes with so few features out-of-the-box. I am working on adding a totals row to an Excel table, which is possible, but you have to take great care to not produce a broken output sheet. I finally implemented some code that looks to work, now I'm adding a unit test for it, and I literally copy the cells from actual.xlsx to expected.xlsx, and when I open expected.xlsx the next time it is broken!?!?!

How can it be broken, I only edited it with Excel, not even with openpyxl. And the cells I copied were generated with openpyxl, but they come from a sheet that is completely fine. So strange.

Might have to do with me specifying totalsRowFunction="custom", but if I don't specify it and write a fixed string/number into the totals row the sheet breaks

When I manually create the table, openpyxl always reads the values in the totals row in expected.xlsx as string, no matter whether I set the cell formatting to General or a specific number format (???). While in actual.xlsx it's always a number. This nonsense is why I usually prefer to copy actual to expected

no issue if i do totalsRowFunction="sum", even if i don't do a sum. okay?

hello cabbages.

What's cabbages a reference to

@xjcl sopython.com/salad

@xjcl have you considered that this might be an Excel issue?

I've honestly given up understanding how Excel decides to interpret nan or inf or the rest of that family.

It's quite possible that the Excel parser can take "nan" and decide that this is an invalid input rather than use the string literal

You could test that quite easily with .fillna("hello") and see if the behaviour is the same between the two files. If it is, then I'm afraid you're on your own on how to get "nan" to actually work from me. But it would narrow things down