Support empty containers in dx() to align with standard Python behavior

[anilbeycorintis]

Describe the current issue

Currently, fd.dx() behaves inconsistently with common Python conventions when given empty containers.

fd.dx()         ✅  # Equivalent to Measure('cell', subdomain_id='everywhere')
fd.dx(None)     ✅  # Same as above
fd.dx([])       ❌  # Raises an error
fd.dx(())       ❓  # Accepted, but becomes Measure('cell', subdomain_id=()), not 'everywhere'
fd.dx(set())    ❌  # Raises an error

This inconsistency affects not only dx but likely ds and other measure-related APIs as well.

If these inconsistencies remain, how can I know which standard Python constructs are safe to use with Firedrake and which are not?

Shouldn't a Python API aim to be consistent with standard Python constructs to ensure intuitive and reliable usage?

Describe the solution you'd like

The API should treat empty containers consistent with both its own handling of None and Python's standard behavior:

>>> sum([])
0
>>> sum(())
0
>>> sum(set())
0
>>> sum(list())
0
>>> sum(tuple())
0

[connorjward]

If these inconsistencies remain, how can I know which standard Python constructs are safe to use with Firedrake and which are not?

I would argue that the issue here is the general sparsity of documentation. I think being a bit strict with respect to the expected input types is fine. For instance I think passing a dictionary here doesn't make sense.

[anilbeycorintis]

Yes that is alright but could you at least support empty tuples if non-empty tuples are supported in Firedrake? That would really really be a great improvement on our code base. We would appreciate it so much. :)

Imagine you have a function that returns tuple[int] values to be sent to fd.dx().

def get_subdomains() -> tuple[int]:
    """Returns the fluid subdomains."""
    result = fetch_result()
    return result

fd.dx(get_subdomains)

This code has to consider the edge case of get_subdomains returning an empty tuple.

Firedrake however does treat empty tuples differently.

Since empty tuples are behaving unexpectedly, we have to complicate our function this way.

def get_subdomains() -> tuple[int] | None:
    """Returns the fluid subdomains."""
    result = fetch_result()
    if len(result) == 0:
        return None
    else:
        return result

subdomains: tuple[int] | None = get_subdomains()
fd.dx(get_subdomains)

It would be really helpful if empty tuples could be treated the same way as None in fd.dx(). This small change would significantly simplify our (and other Firedrake users’) codebases by allowing us to remove unnecessary Optional types and runtime checks.

Please let me know if this makes sense—thanks in advance!

[anilbeycorintis]

If these inconsistencies remain, how can I know which standard Python constructs are safe to use with Firedrake and which are not?

I would argue that the issue here is the general sparsity of documentation. I think being a bit strict with respect to the expected input types is fine. For instance I think passing a dictionary here doesn't make sense.

I think there are two separate points here.

1. Is it really intended that subdomain_id changes among the empty tuple case, None case and no-argument cases?

fd.dx()         ✅  # Equivalent to Measure('cell', subdomain_id='everywhere')
fd.dx(None)     ✅  # Same as above
fd.dx(())       ❓  # Accepted, but becomes Measure('cell', subdomain_id=()), not 'everywhere'

2. This design causes complications on the firedrake user's codebases.

[connorjward]

I agree that this is less than ideal behaviour. The issue is probably from here.

It would probably be best if you could open an issue or submit a fix to UFL as that is where the bug is.

Quickly glancing at the code the argument management for __call__ is (needlessly?) fairly complex so this might be tricky to immediately fix.

[dham]

I agree this is a UFL problem. I note that the comment explaining why the current arguments are the way they are is from 2016 and hence refers to old FEniCS. Perhaps the interface can be changed so that all but the first argument are keyword only. That would make it straightforward to fix the handling of the first argument. This is, however, a discussion for a UFL issue as we need FEniCS buy-in for any changes.