I'll agree that enums are subject to personal taste, and I am opinionated about the syntax and semantics, as should be evident in my library :). On Jan 30, 2013, at 09:13 PM, Giampaolo Rodolà wrote:
1) a const/enum type looks like something which is subject to personal taste to me. I personally don't like, for example, how flufl requires to define constants by using a class.
In practice, I find this quite nice. In my larger projects, I define the enum class an the interface module and often intersperse comments among the enum values so that more documentation is provided to the reader.
It's just a matter of taste but to me module.FOO looks more "right" than module.Bar.FOO.
I almost always 'from module import MyEnum' so typical use looks something like: if thing.color is Color.red: ... elif thing.color is Color.blue: ... Again, in practice, I find it quite readable and just the right level of verbosity.
Also "Colors.red < Colors.blue" raising an exception is something subject to personal taste.
I guess, if you like blue more than red, but what if you like red more than blue? :) Ordered enums just don't usually make sense, and if they really did, you can coerce to int to do the comparison (but again, I've never needed it, so YAGNI).
2) introducing something like that (class-based) wouldn't help migrating the existent module-level constants we have in the stdlib. Only new projects or new stdlib modules would benefit from it.
Sure, but I don't think this is necessarily about converting the stdlib. We rarely do such mass conversions anyway.
3) other than being subject to personal taste, a const/enum type is also pretty easy to implement.
True, depending on the semantics, syntax, and feature you want.
4) I'm getting the impression that the language is growing too big. To me, this looks like yet another thing that infrequent users have to learn before being able to read and understand Python code. Also consider that people lived without const/enum for 2 decades now.
Well, I would agree that the *language* doesn't need them, but that's different than the stdlib. Maybe the stdlib still doesn't need them either. I don't personally care either way except to save me the trouble of writing up another PEP. :) As for the language growing too big, maybe Pycon 2013 is time for another one of Guido's infamous polls! Cheers, -Barry