openpyxl.worksheet.worksheet.append(iterable) returns a list or dict. If iterable was a list, return the list of cells appended matching the order of items. If iterable was a dict, return a dict of cells appended matching the keys of the items.
reasoning
The existing append function works out in 95% of the cases – fire and forget. But in some cases, you want some additional action on the appended cells like formatting or adding a hyperlink. Either you waive your additional requirements or you reimplement append logic to get the appended cells. Not very pythonic.
The proposed extension should not have severe impact on performance since the cells are touched during runtime in a similar manner as returned anyways. No extra loops and no extra objects except the "offer" towards the caller. If the return value is not consumed, it will be garbaged almost immediately. If the return value is consumed, it avoids inefficient workaround implementations by the consumer.
The proposal is backwards compatible since nobody should've used None.
miscellaneous
If the community accepts the proposal but doesn't feel like implementing with all bells and whistles, I'd be happy to assist.
given
openpyxl.worksheet.worksheet.append(iterable) returns None
proposal
openpyxl.worksheet.worksheet.append(iterable) returns a list or dict. If iterable was a list, return the list of cells appended matching the order of items. If iterable was a dict, return a dict of cells appended matching the keys of the items.
reasoning
The existing append function works out in 95% of the cases – fire and forget. But in some cases, you want some additional action on the appended cells like formatting or adding a hyperlink. Either you waive your additional requirements or you reimplement append logic to get the appended cells. Not very pythonic.
The proposed extension should not have severe impact on performance since the cells are touched during runtime in a similar manner as returned anyways. No extra loops and no extra objects except the "offer" towards the caller. If the return value is not consumed, it will be garbaged almost immediately. If the return value is consumed, it avoids inefficient workaround implementations by the consumer.
The proposal is backwards compatible since nobody should've used None.
miscellaneous
If the community accepts the proposal but doesn't feel like implementing with all bells and whistles, I'd be happy to assist.