Improving ElementCollection.update_all to use Element.update #2453

iliketocode2 · 2026-02-16T17:46:41Z

iliketocode2
Feb 16, 2026

Initially raised by @ntoll, this discussion proposes a change in the ElementCollection.update_all() function to eliminate duplicate code.

The code in question is contained within web.py (pyscript/core/src/stdlib/pyscript/web.py).

Lines 700-717: Element.update()
Lines 1143-1154: ElementCollection.update_all()

The current functions are as follows:

    def update(self, classes=None, style=None, **kwargs):
        """
        Update this element's `classes`, `style`, and `attributes`
        (via arbitrary `**kwargs`).

        Convenience method for bulk updates.
        """
        if classes:
            if isinstance(classes, str):
                self.classes.add(classes)
            else:
                for class_name in classes:
                    self.classes.add(class_name)
        if style:
            for key, value in style.items():
                self.style[key] = value
        for name, value in kwargs.items():
            setattr(self, name, value)

    def update_all(self, **kwargs):
        """
        Explicitly update all elements with the given attributes.

        ```python
        collection.update_all(innerHTML="Hello")
        collection.update_all(className="active", title="Updated")
        ```
        """
        for element in self._elements:
            for name, value in kwargs.items():
                setattr(element, name, value)

Currently, update_all bypasses the logic found in update. Thus update_all could break the Element object's internal state since it uses setattr directly. If my understanding is correct, setattr(element, name, value) could replace the classes attribute if a user called collection.update_all(classes="active").

With the proposed changes below, having element.update(classes="active") would correctly call self.classes.add('active'). Also, consolidating this logic makes sure that any future improvements to Element.update are automatically applied to collections.

The change would modify update_all exclusively and would look something like:

-    def update_all(self, **kwargs):
+    def update_all(self, classes=None, style=None, **kwargs):
         """
         Explicitly update all elements with the given attributes.
 
         ```python
         collection.update_all(innerHTML="Hello")
         collection.update_all(className="active", title="Updated")
         ```
         """
         for element in self._elements:
-            for name, value in kwargs.items():
-                setattr(element, name, value)
+            element.update(classes=classes, style=style, **kwargs)

Let me know your thoughts, and I can create a PR if we think this is a change that should be implemented. 😃

ntoll · 2026-02-16T18:19:50Z

ntoll
Feb 16, 2026
Maintainer

OK. Clearly I'm biased here. 🤣

But, this is a good thing to do for several reasons:

It makes the APIs consistent in terms of signatures.
I appreciate how the ElementCollection's update_all is explicit and cannot be confused with plain old update from an Element. Feedback from users was that they couldn't clearly tell which type of object they were dealing with sometimes so this explicitness makes it immediately clear.
By doing the updating in a single place (each element's update function) we have a single point of truth.
It fixes my shonky code (always a good thing), and an oversight on my part, for which I take full responsibility.

I'm happy for this to become a nice small, neat and tidy PR - @WebReflection do you have any further thoughts?

1 reply

ntoll Feb 16, 2026
Maintainer

One thing to further note: this will require changes in our docs too.

WebReflection · 2026-02-17T22:27:51Z

WebReflection
Feb 17, 2026
Maintainer

Element.classList is a pretty simple API that allows add, remove or toggle from any DOM element ... and I am not sure what we are trying to do in here or why wouldn't we just forward the behavior to the native DOM API (as usual, the preferred and fastest way) ...

if you want to add one or more classes without duplicates as attribute:

classes = ['one', 'or', 'more']
class_list = self._dom_element.classList
class_list.add.apply(class_list, classes)

that will have <el class="one or more"> reflected on the DOM, the same applies for remove + there is toggle which is also pretty simple ... I think we missed an opportunity to keep it simple and standard in there, but I might be not following the current proposal entirely, or not be too happy about the current state if it's more convoluted than native DOM API (as in: we're supposed to simplify things in here, not make things more complex).

Happy to learn or explore more, right now I feel like this is a great opportunity to improve previous state with relative ease.

6 replies

ntoll Feb 18, 2026
Maintainer

Sounds like a plan, and we can discuss this in our Friday call.

WebReflection Feb 22, 2026
Maintainer

honestly, in this specific case (or many other DOM related) when I hear "more Pythonic" all I hear is class_list instead of classList and that would be an easy win on our side, we can check (and eventually cache) attempts to reach DOM APIs via snake_case instead of camelCase and, if that's present in the element, we can assume that class_list maps directly to classList and call it an easy win?

edit ... or even having a map of knowing pythonic shortcuts we can use to map to native DOM APIs, as in el.classes.add/remove/toggle that reflects dom_element.classList ... that'd be a win to me, best of both worlds

ntoll Feb 23, 2026
Maintainer

So, I believe the "more Pythonic" aspect of this API was to use a Python collection (set) for classes and a Python dict for styles rather than the underlying browser based API. But you'd need to check. This has some merit since Pythonistas will instinctively understand how these data structures work (and how they relate to the set of unique class names and style key/value items). But then, as you correctly point out @WebReflection - the underlying APIs are pretty simple anyway, and anyone coming from the web-world to PyScript will wonder why we don't just default to them.

@iliketocode2 and I discussed this on Friday and our thinking can be summarised as:

We should make the existing API consistent (minor PR coming soon).
Then we should decide if it's the right API and adjust in view of the community.

As you know, my preference is for simplicity and obviousness.

WebReflection Feb 23, 2026
Maintainer

simplicity and obviousness

agreed, but it depends who you ask to about it ... to me, having just classList API (maybe with a better name) would be simple and obvious, we wrapping something already simple and obvious that also requires extra documentation might be better for Pythonistas but likely unnecessary for "Web folks" that also usually search for APIs on MDN or among standards

ntoll Feb 23, 2026
Maintainer

Totally. This is what makes PyScript so fascinating.

iliketocode2 · 2026-02-25T14:29:41Z

iliketocode2
Feb 25, 2026
Author

I just submitted a pull request for the basic bug fix I had described at the beginning of this discussion. I assume further conversation will be needed to determine the final architecture (i.e., more pythonic or less pythonic) of this module, so these changes are simply to resolve the immediate bug! 😃

0 replies

ntoll · 2026-02-26T13:28:44Z

ntoll
Feb 26, 2026
Maintainer

OK. Now there's a fix - I'll close this comment.

Further pyscript.web based API aesthetic discussions can happen in their own specific thread. 👍

0 replies

Improving ElementCollection.update_all to use Element.update #2453

Uh oh!

iliketocode2 Feb 16, 2026

Replies: 4 comments · 7 replies

Uh oh!

ntoll Feb 16, 2026 Maintainer

Uh oh!

ntoll Feb 16, 2026 Maintainer

Uh oh!

WebReflection Feb 17, 2026 Maintainer

Uh oh!

ntoll Feb 18, 2026 Maintainer

Uh oh!

Uh oh!

WebReflection Feb 22, 2026 Maintainer

Uh oh!

ntoll Feb 23, 2026 Maintainer

Uh oh!

WebReflection Feb 23, 2026 Maintainer

Uh oh!

ntoll Feb 23, 2026 Maintainer

Uh oh!

Uh oh!

iliketocode2 Feb 25, 2026 Author

Uh oh!

ntoll Feb 26, 2026 Maintainer

iliketocode2
Feb 16, 2026

Replies: 4 comments 7 replies

ntoll
Feb 16, 2026
Maintainer

ntoll Feb 16, 2026
Maintainer

WebReflection
Feb 17, 2026
Maintainer

ntoll Feb 18, 2026
Maintainer

WebReflection Feb 22, 2026
Maintainer

ntoll Feb 23, 2026
Maintainer

WebReflection Feb 23, 2026
Maintainer

ntoll Feb 23, 2026
Maintainer

iliketocode2
Feb 25, 2026
Author

ntoll
Feb 26, 2026
Maintainer