Le Mon, 25 Feb 2013 06:45:27 -0800, Eli Bendersky <eliben at gmail.com> a écrit : > For preparing the draft PEP I ran through some stdlib, Twisted and > personal code and there are *tons* of places that just need a simple > enum for some sort of "state", meaningful return value, or similar. There are also *tons* of public APIs which are now ints and would benefit from becoming named values, but only if doing so doesn't break compatibility (i.e. if they are still usable everywhere an int can be used). > I prefer to have a good solution to one problem than a poorer > solution that tries to cover two unrelated problems. For "names for > ints", Nick's named value proposal seems more relevant, but why mix > the two together? Because the whole functionality is not important enough to have two slightly different variations on it in the stdlib? And why is it a poorer solution exactly? Really, there can be two kinds of enum values (or named values): - int-alike values (usable everywhere an int is) - str-alike values (usable everywhere a str is) A third kind of value, which is partly int-compatible but not entirely, sounds like a byzantine subtlety to me. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4