2013/1/30 Eli Bendersky <eliben@gmail.com>:
On Wed, Jan 30, 2013 at 8:27 AM, Barry Warsaw <barry@python.org> wrote:
On Jan 30, 2013, at 08:17 AM, Eli Bendersky wrote:
Barry, since you've obviously given this issue a lot of thought, maybe you could summarize it in a PEP so we have a clear way of moving forward for 3.4 ?
I'm happy to do so if there's a realistic chance of it being accepted. We already have one rejected enum PEP (354) and we probably don't need two. ;)
Reading this thread it seems that many core devs are interested in the feature and the discussion is mainly deciding on the exact semantics and implementation. Even Guido didn't really speak against it (only somewhat against adding new syntax).
Eli
Personally I'm -1 for a variety of reasons. 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. It's just a matter of taste but to me module.FOO looks more "right" than module.Bar.FOO. Also "Colors.red < Colors.blue" raising an exception is something subject to personal taste. 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. 3) other than being subject to personal taste, a const/enum type is also pretty easy to implement. For example, I came up with this: http://code.google.com/p/psutil/source/browse/trunk/psutil/_common.py?spec=svn1562&r=1524#33 ...which is sufficient for my needs. Users having different needs can do a similar thing pretty easily. 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. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/