Different "look and feel" of some built-in functions

[Dieter Maurer]

Steve Keller wrote at 2021-9-25 00:15 +0200:
>"Dieter Maurer" <dieter at handshake.de> writes:
>
>> Steve Keller wrote at 2021-9-24 11:48 +0200:
>> >Why do some built-in Python functions feel so differently:
>>
>> Because the typical use cases are different
>>
>> [...]
>>
>> >while other functions like set.union() and set.intersection() work on
>> >a list of arguments but not on a sequence:
>> >
>> >    set.intersection({1,2,3}, {3,4,5})
>>
>> Those operations are typically applied to a small number
>> of operands. You would need to build an iterator in that
>> case should the functions only accept iterators.
>
>In my experience I need intersection and union on a list of sets, set
>of sets or a map() returning sets much more often.  E.g. in some
>mathematical problems, and in automaton theory (IIRC, computing of LR
>or LALR sets, converting NFA to DFA, minimizing DFA), many graph
>algorithms traversing the nodes (shortest path, ...), and so on).

I, too, occasionally work with set operations on many operands
-- in the context of `Zope`, more precisely `BTrees`.
There, I have both `union(op1, op2)` and `multiunion(iterator)`
(`multiunion` is there primarily for efficiency reasons).

I you often have operations on large sets of operands,
you could define corresponding "convernience functions".



--
Dieter