homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.
History
Date User Action Args
2016年07月11日 01:25:38barrysetrecipients: + barry, eli.bendersky, ethan.furman, John Hagen
2016年07月11日 01:25:38barrylinkissue26988 messages
2016年07月11日 01:25:37barrycreate

AltStyle によって変換されたページ (->オリジナル) /