| Enum Causes Controversy for Python 3.4 |
| Written by Alex Armstrong | ||||||
| Friday, 17 May 2013 | ||||||
|
After years of debate on the issue, a proposal to include an enumeration type in Python 3.4 has been approved. But it has already been criticized as being an awkward compromise. According to Eli Bendersky, who is one of the authors of the Python Enhancement Proposal PEP 435, it has taken a lot of effort to get this far. In his blog post, he refers to: months of intensive discussion - more than a 1000 emails in dozens of threads spread over two mailing lists, and a couple of hundred additional private emails and says: The discussion and decision process has been long and arduous, but eventually very positive. A collective brain is certainly better than any single one; the final proposal is better in a number of ways than the initial one, and the vast majority of Python core developers now feel good about it (give or take a couple of very minor issues). The proposed enumeration type is analogous to those found in other languages. Its abstract states: An enumeration is a set of symbolic names bound to unique, constant values. Within an enumeration, the values can be compared by identity, and the enumeration itself can be iterated over. And the proposal also refers to the fact that the idea of adding an enum type to Python isn't new - a previous attempt to do so was rejected in 2005. One question asked on behalf of the Python Community by Nick Coghlan, who works for the Python Software Foundation as one of the core developers of the CPython reference interpreter, is "Why standardize enums at all?" Writing on his Python Notes site he explains: The idea of standardising enumerations has been kicking around for years. What finally tipped the balance this time? The major factor was a combination of Guido [Van Rossum, Python's creator] being sufficiently interested to rule on the many and varied debatable aspects of Enum runtime behaviour ... The other motivating factor, however, was the ability to use enumerations to improve various error messages emitted by the standard library. Now that PEP 435 has been accepted it has already come in for strong criticism in a post Python's sad, unimaginative Enum by Andrew Cooke in which he describes it as an "awkward compromise" and points to the fundamental failing that the Enum type counts from 1 and so breaks Python's "only one way to do it " dictum since Python counts from 0. It also suffers from the need to manually assign integer values to the enums and from aliases which result if you assign the same integer more than once. Cooke's concern has, however, been taken on board by Coghlan who writes in an email: I believe your concerns about aliasing and the values assigned by the functional API are well founded, so I've taken the liberty of turning those into proposals on the issue tracker as aspects we should revisit once the basic enum implementation is in place. The on-going debate about PEP 435 is an interesting example of how open source software evolves and how languages are designed. It is generally easy to invent a new language, but much harder to introduce a new feature to an existing language because you have to work out its impact on existing syntax and semantics.
Python's sad, unimaginative Enum Python Enumerations and “Good Enough”
Related ArticlesPython 3.3 Overtakes 2.7 - Time To Switch? Grants Awarded To Kivy and NLTK To Boost Python 3 Brython - Python In The Browser
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
Comments
or email your comment to: comments@i-programmer.info
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
Comments
or email your comment to: comments@i-programmer.info
|
||||||
| Last Updated ( Tuesday, 18 March 2014 ) |
