On Oct 1, 2015, at 23:30, Akira Li firstname.lastname@example.org wrote:
Each builtin specifies what type of iterable it accepts but the parameter IS called *iterable*. Are you suggesting to rename the parameters?
I think this is where the confusion arises. No one but you is talking about parameter names. The issue is just about having consistent, well-understood names that can be used in documentation, discussions like this thread, answers on the main Python list or StackOverflow, etc.
The question of exactly which things we need to name (non-iterator iterable, repeatable iterables, repeatable iterables that always iterate the same elements, iterables that don't return self when iterates, iterables that always return a new object each time they're iterafed, …) may be an open question (because you're right that they're not all the same thing, even if they usually overlap), but some subset of those things is relevant often enough that some of them need names.
For example, you could tell the user who had the any/all "bug" that "The way you've coded that function, it only works for re-iterables/collections/whatever, but you're passing it the result of a generator expression, which is an iterator." That (together with a place the user can look up re-iterable/collection/whatever--whether that place is the glossary or the collective mind of the community or whatever) explains the problem without the need for a long explanation on the fact that not all iterables are reusable in the way he's trying to reuse them, and in particular iterators never are, and so on.
The user doesn't then need to change his parameter name from "tests" to "reiterable" or anything like that--he's already got a perfectly good name.
Of course it's not impossible that some of these concepts might also be useful as ABCs and/or static types, in which case it's possible he may want to add an annotation. But that's a separate issue, one which, again, nobody else has raised.