枚举习语：来自不同枚举的值 [英] Enumeration idioms: Values from different enumerations
问题描述
[经许可引用私人电子邮件]
Antoon Pardon写道：
我刚下载了你的enum模块for python [来自Cheeseshop]
并玩了一下。 IMO的一些行为使其不那么有用。
反馈表示赞赏。我希望提供一种明显的方式。 to $>
用Python做枚举。
来自enum import Enum
day = Enum（''mon''，'tue''，''wed''，''thu''，''fri''，''sat''，''sun''）
col = Enum（''red''，''green''，''blue''）
day.wed == col.blue Traceback（最近一次调用最后一次）：
文件"< ; stdin>"，第1行，在？
文件" enum.py"，第100行，__ cmp__
引发EnumValueCompareError（self，other）
enum.EnumValueCompareError：不是来自相同的枚举：
（EnumValue（< enum.Enum对象在0x4020c30c>，2，''wed''），
EnumValue（< enum.Enum对象在0x4021a14c>，2，''' blue''））type（day.mon）== type（col.red）True type（day.mon）是type（col.red）True lst = [day.mon，col.red]
day .fri in lst
从上面可以看出，你提出异常wh en想要比较来自不同enumarations的枚举，但似乎有点奇怪，不同的枚举属于同一类型。
这似乎有点令人困惑。如果
每个Enum实例都有自己独特的EnumValue子类，那是不是更好？那是用于实例化枚举值的
？
我还认为，如果来自不同
枚举的枚举刚刚测试不等，那将会更有用。
我的理由是：枚举的唯一目的是
在该枚举中有一组任意唯一值。
值在不同枚举的上下文中没有任何意义，所以我
看到三种不同的比较结果：
Weekday.mon == Weekday.mon
True Weekday.fri == Weekday.mon
False Colour.blue == Weekday.mon
[...]
enum.EnumValueCompareError：不是来自同一枚举的值
但是，我知道这不是其他Python类型的行为：
23 == 23
真42 == 23
假垃圾邮件 == 23
False
这些案例之间是否存在语义差异？这是不同的
足以想要不同的行为？
是否有一些行为而不是评估为假或者引发
异常，这可能表示不具有可比性？
因为它不能放置来自不同枚举的元素
在列表中并与in运算符一起检查列表中是否有特定的枚举值。
它也可能导致词典出现问题，因为
词典中的键可以是针对订阅中的密钥进行测试。
这些都是有效的问题。我无法看到如何调和这些对不同枚举的价值观的失败比较。
我独自一人在我的三态枚举值比较的视图？可以
其他任何人为不同的枚举值进行辩护为什么不应该比较
比较？
-
\我是隔壁的孩子'想象中的朋友。 - Emo飞利浦|
` \ |
_o__）|
Ben Finney
Ben Finney写道：这些都是有效的问题。我无法看到如何调和这些对不同枚举的价值观的失败以及对比失败的意愿。
我是否一个人处于我对三重状态的枚举值比较的看法？可以
其他人捍卫为什么来自不同枚举的价值不应该比较吗？
虽然我很大程度上是一个不感兴趣的旁观者，但它发生在我，如果你想看看最初想要枚举的原因，那么你可以找到一个很好的理由来捍卫这种观点。
例如，如果枚举旨在降低某些类型错误的可能性（使用典型的XXXX = 3常数
可能更容易出错），那么也许这表明默默地传递
错误是不好的。也就是说，尝试比较
不应该比较的枚举*是*错误（引发异常）*因为*
枚举的全部要点是避免错误在这种情况下。
或许我对人们想要枚举的原因不太了解。
只是一个美容考虑因素吗？ （是的，我已经在C中广泛使用和欣赏它们了很多b / b甚至可能为我的Python代码选择了Enum ...我是
只是一种在这里扮演魔鬼的拥护者。）
-Peter
Peter Hansen< pe *** @ engcorp.com>写道：例如，如果枚举旨在降低某些类型的错误的可能性（使用典型的XXXX = 3常数
可能更多容易出错），或许这表明
默默地传递错误是不好的。也就是说，尝试比较不应该比较的枚举*是*错误（引发异常）*因为*整个枚举点是为了避免在这种情况下出现错误。
除非它可能不是错误。例如，如果我有一个
enum对象的列表，这些对象取自不同类型（比如说我有一套枚举
一周中的几天，一年中的另一个月，等等，以及我使用的
取决于用户是否想要选择
周的日子，一年中的几个月，等等，如果列表中有特定的枚举值，那么想要知道
是完全合理的，并且显而易见的方法是检查
它是否包含my_value in enum_list" ;.如果你提出一个
异常，那就不行了 - 需要一个相对复杂的代码来进行这个
测试。
Python通常使用''==''来表示是相同的值。要做到这一点，
简单的真/假回报就足够了。在提出异常时，你是'b $ b使''==''带来额外的意义（我不确定*那是什么*
虽然）。任何python内置的行为都是那样的吗？蟒蛇标准库
怎么样？
< mike
-
Mike Meyer< mw*@mired.org> http://www.mired.org/home/mwm/
独立的WWW / Perforce / FreeBSD / Unix顾问，电子邮件以获取更多信息。
Op 2005-12-16，Ben Finney schreef< be ************ @ benfinney.id.au>：[引用私人电子邮件许可]
Antoon Pardon写道：我刚刚下载了你的enum模块for python [来自Cheeseshop]
并玩了一下。 IMO的一些行为使其不那么有用。
感谢您的反馈。我希望提供一种明显的方式。使用Python进行枚举。
>>>来自enum import Enum
>>> day = Enum（''mon''，'tue''，''wed''，''thu''，''fri''，''sat''，''sun''）
>>> col = Enum（''red''，''green''，''blue''）
>>>跟踪（最近一次呼叫最后一次）：
文件"< stdin>"，第1行，在？
文件中 enum.py"，第100行，在__cmp__中
引发EnumValueCompareError（self，other）
enum.EnumValueCompareError：不是来自同一枚举的值：
（EnumValue（< enum.Enum object at at 0x4020c30c>，2，''wed''），
EnumValue（< enum.Enum对象位于0x4021a14c>，2，''blue''））>>> ; type（day.mon）== type（col.red）
True>>> type（day.mon）是type（col.red）
True>>> lst = [day.mon，col.red]
>>> day.fri in lst从上面可以看出，当你想要比较来自不同动画的枚举时，你会引发异常，但似乎有点奇怪的是不同的枚举属于同一类型。
这似乎有点令人困惑。如果
每个Enum实例都有自己独特的EnumValue子类，用于实例化该枚举的值，会不会更好？
如果您在比较不同枚举的值时保持当前行为，我肯定会回答
是的。
< blockquote class =post_quotes>我也认为如果来自不同
枚举的枚举刚刚测试不等，那将会更有用。
我的理由是：唯一的目的是枚举是指在该枚举中具有一组任意唯一值。
值在不同枚举的上下文中没有意义，所以我看到三种不同的比较结果：
>>> Weekday.mon == Weekday.mon True>>> Weekday.fri == Weekday.mon False>>> Colour.blue == Weekday.mon [...]
enum.EnumValueCompareError：不是来自相同枚举的值
然而，我知道这不是其他Python类型的方式表现：
>>> 23 == 23 True>>> 42 == 23错误>>> "垃圾" == 23
错误
这些案例之间是否存在语义差异？是否有这种差异足以想要不同的行为？
是否存在除评估为假之外的一些行为？或者引发
例外，这可能表示不具有可比性？
这是一个棘手的问题，因为AFAIU python不会有明确的
指南。我也有这样的印象：比较是因为两个不同的原因而使用
。
第一种是以数学的方式比较事物
如何比较事物很重要。
第二种更像是一种订购机制。一个字符串是否比一个int更大或者反之亦然，并不重要的是重要的是
这个顺序是一致的并且可以用于二进制搜索，树
和其他组织数据的结构。
现在python只有一个比较运算符集合，它们可以导致冲突。例如，可以在集合上施加订单
用于此类结构但违反正常订单
基于子集的集合。
我在这里唯一的建议是看看PEP 3000，它说：
不同类型之间的==和！=以外的比较会提高
异常，除非类型明确支持。
这似乎意味着==和！=不应该引发异常
但是>，> =，<，< =应该。
-
Antoon Pardon
[quoting private email with permission]
Antoon Pardon wrote:
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.
Feedback is appreciated. I''m hoping to provide a "one obvious way" to
do enumerations in Python.
from enum import Enum
day = Enum(''mon'', ''tue'', ''wed'', ''thu'', ''fri'', ''sat'', ''sun'')
col = Enum(''red'', ''green'', ''blue'')
day.wed == col.blue Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "enum.py", line 100, in __cmp__
raise EnumValueCompareError(self, other)
enum.EnumValueCompareError: Not values from the same enumeration:
(EnumValue(<enum.Enum object at 0x4020c30c>, 2, ''wed''),
EnumValue(<enum.Enum object at 0x4021a14c>, 2, ''blue'')) type(day.mon) == type(col.red) True type(day.mon) is type(col.red) True lst= [day.mon, col.red]
day.fri in lst As can be seen from the above, you raise an exception when one wants
to compare Enums from different enumarations, but it seems a bit
strange that different enumerations belong to the same type.
This does seem a point that could be confusing. Would it be better if
every Enum instance had its own unique subclass of EnumValue, that was
used to instantiate values for that enumeration?
I also think it would be more usefull if enums from different
enumerations just tested unequal.
My rationale for this is: The only purpose of an enumeration is to
have a set of arbitrary unique values within that enumeration. The
values make no sense in the context of a different enumeration, so I
see three different comparison results:
Weekday.mon == Weekday.mon True Weekday.fri == Weekday.mon False Colour.blue == Weekday.mon [...]
enum.EnumValueCompareError: Not values from the same enumeration
However, I''m aware that this is not how other Python types behave:
23 == 23 True 42 == 23 False "spam" == 23
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"?
Because as it is you can''t put elements from different enumerations
in a list and check with the in operator if a specific enum value is
in the list.
It could also cause problems for dictionaries, since keys in
dictionaries can be tested against a key giving in a subscription.
These are valid concerns. I can''t see how to reconcile these against
the desire for values from different enums to fail comparison.
Am I alone in my tri-state view of enumeration value comparisons? Can
anyone else defend why values from different enumerations should not
compare?
--
\ "I was the kid next door''s imaginary friend." -- Emo Philips |
`\ |
_o__) |
Ben Finney
Ben Finney wrote:These are valid concerns. I can''t see how to reconcile these against
the desire for values from different enums to fail comparison.
Am I alone in my tri-state view of enumeration value comparisons? Can
anyone else defend why values from different enumerations should not
compare?
While I''m largely a disinterested bystander, it occurs to me that if you
look at the reasons behind wanting enumerations in the first place, you
might find a good reason to defend this view.
For example, if enumerations are intended to reduce the likelihood of
certain types of errors (where the use of typical XXXX=3 "constants"
might be more prone to errors), then perhaps this suggests that passing
errors silently is bad. That is, trying to compare enumerations that
should not be compared *is* an error (raising an exception) *because*
the whole point of enumerations is to avoid errors in such cases.
Or perhaps I''m off the mark as to why people want enumerations. Is it
just a cosmetic consideration? (Yes, I''ve used and appreciated them
extensively in C and might even pick up Enum for my Python code... I''m
just sort of playing devil''s advocate here.)
-Peter
Peter Hansen <pe***@engcorp.com> writes:For example, if enumerations are intended to reduce the likelihood of
certain types of errors (where the use of typical XXXX=3 "constants"
might be more prone to errors), then perhaps this suggests that
passing errors silently is bad. That is, trying to compare
enumerations that should not be compared *is* an error (raising an
exception) *because* the whole point of enumerations is to avoid
errors in such cases.
Except it might not be an error. For instance, if I''ve got a list of
enum objects taken from various types (say I''ve got one set of enums
for days of the week, another for months of the year, and so on, and
which I use depends on whether the user wants to select days of the
week, months of the year, etc), it makes perfect sense to want to know
if a specific enum value is in the list, and the obvious way to check
it is with "my_value in enum_list". That won''t work if you raise an
exception - it takes a relatively convoluted bit of code to make this
test.
Python generally uses ''=='' to mean "is the same value". To do that, a
simple true/false return is enough. In raising an exception, you''re
making ''=='' carry an extra meaning (I''m not sure *what* that is,
though). Do any python builtins behave that way? How about anything in
the python standard library?
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Op 2005-12-16, Ben Finney schreef <be************@benfinney.id.au>:[quoting private email with permission]
Antoon Pardon wrote: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.
Feedback is appreciated. I''m hoping to provide a "one obvious way" to
do enumerations in Python.>>> from enum import Enum
>>> day = Enum(''mon'', ''tue'', ''wed'', ''thu'', ''fri'', ''sat'', ''sun'')
>>> col = Enum(''red'', ''green'', ''blue'')
>>> day.wed == col.blue
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "enum.py", line 100, in __cmp__
raise EnumValueCompareError(self, other)
enum.EnumValueCompareError: Not values from the same enumeration:
(EnumValue(<enum.Enum object at 0x4020c30c>, 2, ''wed''),
EnumValue(<enum.Enum object at 0x4021a14c>, 2, ''blue''))>>> type(day.mon) == type(col.red)
True>>> type(day.mon) is type(col.red)
True>>> lst= [day.mon, col.red]
>>> day.fri in lstAs can be seen from the above, you raise an exception when one wants
to compare Enums from different enumarations, but it seems a bit
strange that different enumerations belong to the same type.
This does seem a point that could be confusing. Would it be better if
every Enum instance had its own unique subclass of EnumValue, that was
used to instantiate values for that enumeration?
If you decide on keeping the current behaviour when comparing
values of different enumerations, I would definitely answer
yes.
I also think it would be more usefull if enums from different
enumerations just tested unequal.
My rationale for this is: The only purpose of an enumeration is to
have a set of arbitrary unique values within that enumeration. The
values make no sense in the context of a different enumeration, so I
see three different comparison results:
>>> Weekday.mon == Weekday.mon True >>> Weekday.fri == Weekday.mon False >>> Colour.blue == Weekday.mon [...]
enum.EnumValueCompareError: Not values from the same enumeration
However, I''m aware that this is not how other Python types behave:
>>> 23 == 23 True >>> 42 == 23 False >>> "spam" == 23
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"?
This is a difficult question, because AFAIU python doesn''t have clear
guidelines for this. I also have the impression that comparisons are
used for two different reasons.
The first is compare things in a mathematical kind of way in which
how things are compared is important.
The second is more an ordering mechanisme. Whether a string is greater
than an int or vice versa, is not imporant what is important is that
this order is consistent and can be used in binary searches, trees
and other structures to organise data.
Now python has only one collection of compare operators which can
cause conflicts. For instance, one could impose an order on sets
to use for such structure but that goes against the normal order
on sets which is based on subsets.
The only advise I have here is look at PEP 3000 that states:
Comparisons other than == and != between disparate types will raise
an exception unless explicitly supported by the type.
Which seem to imply that == and != should not raise an exception
but >, >=, <, <= should.
--
Antoon Pardon
这篇关于枚举习语：来自不同枚举的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
