This could be further simplified to:

    if not np.iterable(val):
        val = [val]
    return ','.join(escape_func(r'\\\1', str(x)) for x in val
                    if x is not None)

Sorry - that doesn't work. strings are iterable so that test is incorrect.

I appreciate what you're doing here but I have a suggestion (I'm not trying to be snarky so hopefuly this doesn't come across that way). When I make a PR, I try to change as little as possible to fix the bug. I agree that you're suggestions are improvements but they are not related to the bug fix, they're just general code improvements. Rather than telling me what to do, me doing it, merging it, and waiting for more reviews, it seems like it would be simpler and more efficient to merge the PR to fix the bug and then you can make whatever code improvements you want and commit them.

Good catch. Thanks for seeing that, and thanks for your feedback on the process!

Thinking of it, it should rather be if isinstance(val, str):, which is preferrable, because the function accepts any iterables and not just lists (even though the function is private and documented to only take lists). Additionally, the rewritten version does only have one joint code path for strings and lists. This reduces the risk of omissions in testing, and also the risk that only one of the paths will be modified some time in the future. Being defensive and picky about such things adds to the stability of the code, in particular in large projects with many users and contributors.

My philosophy of PR reviewing (skip if you're not interested):
I wouldn't have made any suggestions related to existing code. But this one is a completely new function. For new code I'd like to have it as concise and good quality as possible before merging. Merge+fix needs a second full (two approval) review. It adds clutter to the log, which makes it harder finding out later when something really changed.
Yet, for me personally it would still be faster to accept + fix. But, I believe that the review process is also a good way of learning. If PR authors contribute multiple times, their future PRs will be better. I intentionally invest time in this when reviewing.

In summary, I still would like to see the change with the str-check-variation above. Please let me know if you feel that's too cumbersome. I would then pick up from here myself. We're really grateful for your contribution. I'd also happy to hear from you if you feel this back-and-forth review is too annoying. That may help me to better judge how far to go and what to accept in future reviews.

OK, fair enough. I think I was feeling that way because I felt like that function wasn't really new code, just a refactoring of the existing code.

I don't think that testing for str will work either since some of the properties are integers (font size). Those get converted to string in the non-list path. So we would need to do something like

    if not np.iterable(val) or isinstance(val, str):
        val = [val]

I've updated the code to that.

Thanks! 👍