While this makes for a somewhat cleaner view, I think we'd be better off not implementing rowpans. For example sorting by the various index columns is less intuitive if the index isn't rendered the same as other columns.

A new implementation is used without rowspans.

Let's try to actually refer to the original BigFrames DataFrame when deciding which index columns to render or not. In particular, we should not render the index if the BigFrame DataFrame has a NULL index.

My new version correctly refers to the original BigFrames DataFrame's _block.has_index property. If has_index is False (indicating a "NULL index"), the _prepare_dataframe_for_display method ensures that a default "Row" column is inserted for display instead of attempting to render a non-existent index. My recent refactoring preserved this established logic.

This syntax was added in Python 3.10.https://peps.python.org/pep-0604/

Currently, we are supporting Python 3.9

Please wait to use this syntax until we drop Python 3.9. I have filed b/470438395 to track this.

I'd prefer we initialize this to false ininit instead of relying on hasattr.

Also, consider multi threading. We probably need a lock to fully prevent two table htmls being set at the same time.

Here is what I change to: (1) self._setting_html = False and self._setting_html_lock = threading.Lock() were added to the TableWidget.init method
(2) The _set_table_html method was refactored to use with self._setting_html_lock: and the self._setting_html flag to prevent race conditions during HTML rendering. The flag is reset in the finally block to ensure it's always released.

I would prefer a context manager instead of a try/except/finally block. That way we can be more explicit about what the intention is. Are you sure you want to competely skip setting the html if another thread tries to set it? If not, just do a with block with a lock here. If so, please explain why it's safe to skip.

Aside: I would actually expect the opposite here, where later set calls would interrupt any set call that is currently running.

A threading.Lock was used as a context manager (with self._setting_html_lock:) within _set_table_html. The logic now explicitly uses the _setting_html flag within this locked context to control whether HTML rendering proceeds or is skipped, ensuring thread safety and clear intent.

This looks like it's intended for retries, but this is a very unsafe way to do that, if is the intention.

Also, I don't understand how this change relates to adding columns for mutiindex.

No, it is not related to multiindex display. I mix so many features into the same pr. I have refactor them out. And move this one to a separate new branch.