Raymond Hettinger added the comment: [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). ---------- nosy: +rhettinger _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23591> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
