I think this is just a historical artifact. These functions were introduced quite a while ago, when fluid interfaces were not all the rage. Since then everyone got used to them. (So yes, you can write it of as "bad design").
Could these functions could be retrofitted to lists? Possibly, but it was not and should not have been done.
There should be one-- and preferably only one --obvious way to do it.
Second, and most importantly,
reduce and many other functions work not just with lists but with anything that's iterable. They work on tuples, sets, dicts, and, most importantly, any user-defined classes that implement iteration (via
__iter__) or generators (via
So, every iterable or generator should somehow receive their own implementations of
reduce, and probably a bunch of other functions that accept an iterable / generator and return something compatible. This would require that any existing class that happen to be iterable not to expose names like
reduce. Code-breaking changes are very much frowned-upon by Python maintainers and community alike.
Instead, you can wrap things into your own class that offers the additional interface, and enjoy either the fluid style you mention, or pipe style, or anything else.