"Steven D'Aprano" <[EMAIL PROTECTED]> wrote > A list of X is like a box containing X,
and in another post > A list is a container. I think it is misleading, if not wrong, to refer to Python collections as 'containers', 'boxes', or similar. A object in a box cannot be in another disjoint box. A object in a box cannot be in the box a second time. But both 'cannot's are 'can's for Python objects in respect to Python collections. So, bad metaphor. (Yes, CPython implements the association of list positions with objects by putting an instance/copy of the id/address of the implemented object 'in' a particular position in a block of memory, but even then, the object itself in not 'in' the list block. And that is so because of the need for multiple associations for each object. Beside which, we are discussing the abstract notion of the empty enumeration.) > You can take the elements away and still have the container left. I would say instead that you have an empty roster ;-) I suspect that the notion of empty set was once controversial. It certainly gives some set theory beginners a pause. > But an enum is not a container. But neither, I claim, is a list. So to me, you have not drawn a distrinction, and therefore no justification for different treatment. To me, the enum proposal is for an immutable ordered set (rather than multiset) with a friendly interface. So, like other posters, I have no problem with one that is empty. I also expect enum() to return such because that is GvR policy for builtin type constructors. To me, 'I can't think of a use for X' is insufficient reason to prohibit X in Python. You also need an 'X is tricky/difficult to implement' or 'X is harmful' claim. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
