Message270148
| Author |
barry |
| Recipients |
John Hagen, barry, eli.bendersky, ethan.furman |
| Date |
2016年07月11日.01:25:37 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<20160710212532.166e4ae2@python.org> |
| In-reply-to |
<1468196837.16.0.131395096728.issue26988@psf.upfronthosting.co.za> |
| Content |
On Jul 11, 2016, at 12:27 AM, Ethan Furman wrote:
>Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum.
>
>In terms of capability, aenum is the most advanced, followed by the stdlib
>enum, and finally enum34 (really the only difference between stdlib and
>enum34 is the automatic definition order).
>
>The only advantage of enum34 over aenum is if it works in enum34 it will
>definitely work in the stdlib, whilst aenum has features not in the stdlib
>(speaking from a user point of view).
>
>So I haven't decided, but at this moment I'm not excited about the prospect.
>:(
>
>What I'll probably do is put enum34 in bug-fix only mode.
It's been useful to have a standalone version of the stdlib module, and in
fact, I maintain the enum34 package in Debian. However, we only support that
for Python 2 since we don't have to worry about any Python 3 versions before
3.4 (and even there, 3.5 is the default for Stretch and Ubuntu 16.04 LTS).
We do have reverse dependencies for python-enum34, but given that we *really*
want people to port to Python 3, I'm not sure I really care too much any more
about enum34 in Debian. |
|