This sounds like a nice idea in theory, and makes a lot of sense for polished, publicly visible libraries where convenience trumps simplicity, but the edge case

This sounds like a nice idea in theory, and makes a lot of sense for polished, publicly visible libraries where convenience trumps simplicity, but the edge cases can lead to confusing failures and bloat otherwise simple code — as you noted, your example code appears to work for arbitrary objects but actually fails for `str` or `bytes`. A great case study in the issues here is Pandas, which routinely allows arguments to be columns, lists of columns, string column labels, lists of string column labels, and so on. It works surprisingly well, but at the cost of inventing a new semantic distinction between `list` objects and other sequence types like `tuple` — someone unfamiliar with Pandas who thinks “Why does this need to be a list comprehension when a generator expression will do?” is likely introducing a bug. Another subtle issue is that code permissive with inputs is harder to extend via wrapper code. Suppose you have a function that does some sort of processing for any number of given datetimes, but also accepts integer seconds since 1970-01-01, a formatted date string, or any mixed sequence of these types. If you need to write a wrapper that first rounds all times to the most recent hour, your task is much easier if the only accepted type is `Iterable[datetime]`.