Seeking feedback on a high-perf alternative to forms.utils.flatatt

Using Django
1

Hi Djangonauts, I’m working on a library (similar to Iommi) and found that django.forms.utils.flatatt is adding ~100ms of overhead when rendering thousands of elements in a table. I’m considering using the following custom implementation for better performance, since Python 3.7+ dicts are ordered, I’m skipping sorted()

_is_valid_key = re.compile(r"^[a-zA-Z0-9\-_@:\.]+$").match
def _render_attrs(attrs: dict[str, Any]) -> SafeString:
    if not attrs:
        return mark_safe("")

    chunks = []
    for key, value in attrs.items():
        if not _is_valid_key(key):
            raise ValueError(f"Invalid attribute name: {key}")

        if value is None or value is False:
            continue

        if value is True:
            chunks.append(f" {key}")
            continue
        
        chunks.append(f' {key}="{conditional_escape(value)}"')

    return mark_safe("".join(chunks))
  1. are there flatatt edge cases this would break?
  2. Also can I replace conditional escape with the following snippet I copied from Iommi? I’m building a similar library where attrs are defined by developers at the code level.
# replacing: chunks.append(f' {key}="{conditional_escape(value)}"')

if isinstance(value, Promise):
	value = str(value)
if hasattr(value, "__html__"):
	v = value.__html__()
else:
	v = f"{value}".replace("&", "&").replace('"', """)
chunks.append(f' {key}="{v}"')

Given that these attributes will be mostly developer-defined, is this ok, or is conditional_escape the non-negotiable standard here?

I’ve added a regex check (_is_valid_key) for the attribute keys. In my profiling, this only adds about 10ms of overhead, which I find acceptable for the added safety. I noticed flatatt itself doesn’t escape keys but I am concerned I might be missing some context that allows Django to skips it. can I skip key escaping?

Appreciate any insights!

2

Your custom escaping might introduce XSS cause it does not handle all necessary characters. In particular, characters like < and > are not escaped, which could allow injected HTML.

3

I think there might be a slight misunderstanding! My custom function uses conditional_escape() (see the first snippet).

​The Iommi snippet was a separate point of comparison for discussion. I noticed they only escape & and " because, inside double-quoted attributes, those are the primary characters that can break the HTML context. I brought it up to ask if that ‘minimalist’ approach is considered safe enough for developer-defined attributes in the Django ecosystem, or if conditional_escape is the non-negotiable standard.

​I’m exploring this because my profiling showed a >30ms gain by switching to the more targeted escaping method. My goal is to keep the safety of my first snippet but optimize the rendering speed. Do you think the Iommi approach is too risky for a Django-adjacent library? Or am I missing something about Iommi?

4

Iommi approach is valid in strict attribute context. But it could be risky. You are not missing anything major. But i think you should not keep django adjacent library default. Your approach is fine but i would be cautious about using minimalist approach