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 ethan.furman
Recipients John Hagen, barry, eli.bendersky, ethan.furman
Date 2016-07-11.00:27:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468196837.16.0.131395096728.issue26988@psf.upfronthosting.co.za>
In-reply-to
Content
Yeah, I think the public interface will just be the AutoEnum and AutoNameEnum style.

---

> Will these features go into enum34?

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.
History
Date User Action Args
2016-07-11 00:27:17ethan.furmansetrecipients: + ethan.furman, barry, eli.bendersky, John Hagen
2016-07-11 00:27:17ethan.furmansetmessageid: <1468196837.16.0.131395096728.issue26988@psf.upfronthosting.co.za>
2016-07-11 00:27:17ethan.furmanlinkissue26988 messages
2016-07-11 00:27:15ethan.furmancreate