What the Pythons docs means by "container" ?

[candide]

> 
> Shrug. It is a useful descriptive term when you want to talk about things. You

Python Language Referenceb (PLR) is expected to give formal and acurate definition, not "descriptive term to talk about things".

> might keep in mind that a "container"'s _primary_ purpose is usually its 
> containing function. So a list. But not so some arbitrary object, even though 

"containing function" ? Does PLR document this "containing function"?


> most objects have references to other objects.

have or contain ;)  ? 


 
> Duck typing again: this bases the term on behaviour, not memory use.

Again this is undocumented. Compare with the definition of duck-typed iterators, cf. https://docs.python.org/3.2/library/stdtypes.html#iterator-types

On the other hand, recall that the new behavior of range since Python 3 is motivated by memory considerations, quoted from the doc : 



--------------------
The advantage of the range type over a regular list or tuple is that a range object will always take the same (small) amount of memory, no matter the size of the range it represents (as it only stores the start, stop and step values, calculating individual items and subranges as needed).
--------------------


> Neither of these things has a .__contains__ method; the "in" operator falls 
> back to iteration if there is no .__contains__.


The documentation is fuzzy and inconsistant here: containers are supposed to implement the membership test, dixit the doc. 


> 
> A container usually lets you test "in" in a nondestructive/nonconsuming

"usually" ? I need something more acurate ;)


> fashion. An iterable can be "in"ed, but it will be consumed. So iterables are 
> not, of themselves, containers.

First this is undocumented. Second, range objects are considered as iterable by the doc. And you are telling us that an iterable is not a container. And range has a __contains__ method.

> 
> So, range? A range object knows its bounds and state; it can answer "in" 
> without consuming the range iteration, so it is effectively a container.

Again, this no-consuming feature is completely undocumented. And unconvincing: do you regard a linked list as not being a container ?