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 rhettinger
Recipients barry, eli.bendersky, ethan.furman, ezio.melotti, martin.panter, r.david.murray, rhettinger, serhiy.storchaka, veky, vstinner
Date 2016-08-30.17:23:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1472577812.55.0.612806035929.issue23591@psf.upfronthosting.co.za>
In-reply-to
Content
[Ethan]
> My experience is that a module maintainer, or somebody claiming to speak
> for the module maintainer, can close any issue in their area at any 
> time regardless of the number of core devs in favor of a change.

Ethan, it is still up to you and the other module maintainers to decide whether this goes in or whether to defer it for a release cycle.  If you have any concerns about having too many enum variants and think this is at odds with your goals for the module, say so here and we can resolve it at the sprints.  On the other hand, if you're happy with it, we should get it applied as soon as possible.

[Serhiy]
> If general IntFlags will not added, I'm going to open separate issues
> for adding specialized class for every particular case (re, os, etc).

When enum went in, I thought Guido had said and everyone agreed to refrain sweeping through the standard lib and applying enums broadly to long standing and stable APIs.  Perhaps something has changed since them but there was a clear intention to show restraint, let enums mature, respect stable APIs, and to wait for demonstrated need (i.e. actual rather than imagined user difficulties).
History
Date User Action Args
2016-08-30 17:23:32rhettingersetrecipients: + rhettinger, barry, vstinner, ezio.melotti, r.david.murray, eli.bendersky, ethan.furman, martin.panter, serhiy.storchaka, veky
2016-08-30 17:23:32rhettingersetmessageid: <1472577812.55.0.612806035929.issue23591@psf.upfronthosting.co.za>
2016-08-30 17:23:32rhettingerlinkissue23591 messages
2016-08-30 17:23:32rhettingercreate