&gt; Is that a problem in practice in Python?<p>&gt; I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs).<p>Not really a problem, but if you&#x27;re writing more than a one-off script, such as a module you plan on sharing, it may be common that you get a mixture of concrete types coming in depending on the app and platform. I think in practice, it&#x27;s actually beneficial to assume you do not know the core type of collection (if your operations will work with many&#x2F;all of them).<p>For example, a range object or generator in Python 3, but a list in Python 2. And then someone else comes along and uses your modules with sets.<p>So with &quot;fruits&quot; (or something like &quot;fruit_iter&quot; for anyone who disagrees with plural naming), you know that you can safely iterate through it. But you may not be able to do random access, or reassignment of elements. There might be times when this matters, in which case you&#x27;d want to enforce a specific type.<p>The only thing I do not like about this is that in Python strings are also iterables. So the difference between passing &quot;Apple&quot; and [&quot;apple&quot;] can be quite large, and yet your program will iterate through &quot;a&quot;, &quot;p&quot;, &quot;p&quot;, &quot;l&quot;, &quot;e&quot; with no complaints. The worst experience I&#x27;ve had with this was working with a web API that would return either an array of strings, or only a string if there was one result (not a 1-element array), or a dictionary of objects if there were many results. 99% percent of the time it returned the array of string, and since strings and dictionaries are iterable, it took me a while to notice the bug.<p>I ought to learn Perl, because that&#x27;s pretty cool. You&#x27;re right that that example is terrible to read, haha, but I&#x27;m sure there are scenarios where it&#x27;s helpful.