Le Mon, 25 Feb 2013 06:45:27 -0800, Eli Bendersky <eli...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
