Why not

?

list_accumulate is not really doing anything.

It is doing something: it's allowing exactly one positional argument, thus restricting the arguments to what is documented.

(It also allows to add better error checking at some point.)

fair enough

Yeah I had considered whether to forward more arguments to python accumulate, but:

• I don't think there is an ergonomic way to pass a binary function
• Passing initial would be roughly equivalent to ([initial_elem] + input_list) | accumulate) so I don't think it's worth adding an optional argument.

(It also allows to add better error checking at some point.)

What do you have in mind ? I could just as well add it now.

Somethings like checking for args and kward and raising an exception in there is some ?

What do you have in mind ? I could just as well add it now.

Checking whether the sequence is actually a sequence.

With from collections.abc import Sequence you can use if not isinstance(sequence, Sequence): to test it.

(This also accepts strings as sequences. That's generally not so great, but here strings are also OK, I guess.)

Do you have time to work on this before say in a week?

Thinking back on this, I'm wondering if I should add that. There is already some quite readable errors message coming directly from accumulate, for instance I I tried to feed an integer to the implementation as-is:

TASK [filter_accumulate : Test accumulate filter] ******************************
fatal: [testhost]: FAILED! => {"msg": "The conditional check '1 | community.general.accumulate == 1' failed. The error was: Unexpected templating type error occurred on ({% if 1 | community.general.accumulate == 1 %} True {% else %} False {% endif %}): 'int' object is not iterable. 'int' object is not iterable"}

However, the filter accepts some input which, while they might be useful, could be questionnable from a correctness POV.

TASK [filter_accumulate : debug] ***********************************************
ok: [testhost] => {
    "{'test': 1, 'ee': 1} | community.general.accumulate": [
        "test",
        "testee"
    ]
}

-> this one errors when checking for a Sequence type.

Wdyt ? I would tend to got the more permissive way, and document the unobvious cases, but I don't have strong opinions.

Also, it appears that checking for Sequence does not catch subtler invalid case, such as non compatible list members :

TASK [filter_accumulate : Test accumulate filter] ******************************
fatal: [testhost]: FAILED! => {"msg": "The conditional check '['ac', 1] | community.general.accumulate == ['ac', 'ac1']' failed. The error was: Unexpected templating type error occurred on ({% if ['ac', 1] | community.general.accumulate == ['ac', 'ac1'] %} True {% else %} False {% endif %}): can only concatenate str (not \"int\") to str. can only concatenate str (not \"int\") to str"}

-> this one errors when checking for a Sequence type.

If you really want to do that, you can always use the | list filter to convert the dict to a list (of its keys) first.

Also, it appears that checking for Sequence does not catch subtler invalid case, such as non compatible list members :

Obviously it cannot catch all invalid input, but it can catch some of the more obvious ones.

Wdyt ? I would tend to got the more permissive way, and document the unobvious cases, but I don't have strong opinions.

I would definitely check for Sequence.