Enumeration idioms: Values from different enumerations

[Ben Finney]

Transitivity within any single enumeration plus transivity of
equivalence across multiple enumerations, should be enough for most
needs, no?

+1 to transitivity within an enumeration. -1 to transitivity across
enumerations. If they're supposed to be equivalent, why are you
separating them into different enumerations at all?

The whole point of an enumeration, as I see it, is to have a set of
values that are only meaningfully equal or sequenced within that
enumeration.

 

[Ben Sizer]

Okay, so I was wrong to say that nobody was seriously suggesting that sort
of behaviour.

I was working under what looks to have been an incorrect assumption
that someone was looking for a way to do the above. After all, it was
mentioned in what seemed like seriousness. I can't think of a use case
for it, myself.

Enums are not conceptually subclasses of integers. Integers just happen to
be a useful method to implement enumerations.

Aren't they? They have discrete values, can be ordered and compared for
equality, etc. I think the 'numerate' part of 'enumeration' is a hint
here. They certainly don't look much further from being integers than
booleans do. But, if nobody actually needs the behaviour I described
before, this point is irrelevant.

 

[Steven D'Aprano]

Aren't they? They have discrete values, can be ordered and compared for
equality, etc.

Just like:

mammal, reptile, amphibian, bird, fish

They are discrete values, they can be ordered in many different ways
(alphabetically, by biological clade, by average number of genes, etc),
and compared for equality (fish is not bird). But they aren't numbers.

It is true that you can create a one-to-one mapping from integers to
enums, but then you can also create a one-to-one mapping from William
Shakespeare's sonnets to enums. That second implementation is,
unfortunately, rather impractical.

I think the 'numerate' part of 'enumeration' is a hint
here.

It certainly is a hint, but not of what you think. It means they are
countable, not that they are numbers. You could try looking "enumerate"
up in the dictionary: it means to count, as in "by the time she finished
enumerating all my flaws, I felt three inches high".

They certainly don't look much further from being integers than
booleans do.

You think?

hamburger, steak, fish, chicken, pizza

What meaning do you give to steak**fish? Should that meaning change if I
happened to have written pizza first instead of last?

The fact that they can be counted shouldn't fool you into thinking they
are numbers.

 

[eswald]

I just downloaded your enum module for python [from the Cheeseshop]
and played a bit with it. IMO some of the behaviour makes it less
usefull. [...]
I also think it would be more usefull if enums from different
enumerations just tested unequal.

[...]

However, I'm aware that this is not how other Python types behave:
False

Is there a semantic difference between these cases? Is that difference
enough to want different behaviour?

Is there some behaviour other than "evaluate to False" or "raise an
exception", that could indicate "not comparable"?

Yes: return NotImplemented. Note that the == operator automagically
returns False in this case.
NotImplemented

This way, the user could explicitly call __eq__ and check for
NotImplemented if he desires the exceptional behavior.

- Eric

 

[Ben Finney]

Yes: return NotImplemented. Note that the == operator automagically
returns False in this case.

NotImplemented

This way, the user could explicitly call __eq__ and check for
NotImplemented if he desires the exceptional behavior.

Thanks, I was unaware of the standard usage of NotImplemented. That
seems like a sensible solution.

<URL:http://docs.python.org/ref/types.html#l2h-29>

 

[Bengt Richter]

Thanks, I was unaware of the standard usage of NotImplemented. That
seems like a sensible solution.

<URL:http://docs.python.org/ref/types.html#l2h-29>

OTOH, that says the truth value is True, so this does not fail:

Which seems counterintuitive. The explicit value test

would succeed irrespective of truth value,
but it seems contorted and unpythonic to have to write
Traceback (most recent call last):

to get the effect you might naively expect from


I wonder what the rationale for the NotImplemented True truth value was, as opposed to False.

On the third hand, I recently posted an idea of using NotImplemented
as a (handy because predefined) logically true sentinel value to return
from a test function to distinguish not_applicable from applicable_and_ok
when desired, yet allowing assert testfun(...) to succeed either way.
That code would have to use another boolishly True sentinel if NotImplemented
were changed to have False truth value.

Maybe it would be useful to have a couple of builtin sentinels like TrueSentinel
and FalseSentinel (or sentinel_t and sentinel_f or pick some names ;-) so we
wouldn't be tempted to misuse unique builtins like NotImplemented and Exception etc.

Regards,
Bengt Richter

 

[Max]

You think?

hamburger, steak, fish, chicken, pizza

What meaning do you give to steak**fish? Should that meaning change if I
happened to have written pizza first instead of last?

What meaning do you give to True**False?

The fact that they can be counted shouldn't fool you into thinking they
are numbers.

--Max

 

[Steven D'Aprano]

What meaning do you give to True**False?

Given that True == 1 and False == 0 in Python (which in my opinion is
unfortunate), then it is obviously 1.

True booleans don't support arithmetic operators like **, and neither
should enums.