PEP 354: Enumerations in Python

[Terry Reedy]

"Steven D'Aprano" <steve at REMOVETHIScyber.com.au> 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