| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next


Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

Last 100 entries

Neural Nets Applied to Go; Programming, Business, Social Contracts; Distributed Systems for Fun and Profit; XML and Scheme; Internet Radio Stations (Curated List); Solid Data About Placebos; Half of Americans Think Climate Change Is a Sign of the Apocalypse; Saturday Surf Sessions With Juvenile Delinquents; Ssh, tty, stdout and stderr; Feathers falling in a vacuum; Santiago 30m Bike Route; Mapa de Ciclovias en Santiago; How Unreliable is UDP?; SE Santiago 20m Bike Route; Cameron's Rap; Configuring libxml with Eclipse; Reducing Combinatorial Complexity With Occam - AI; Sentidos Comunes (Chilean Online Magazine); Hilary Mantel: The Assassination of Margaret Thatcher - August 6th 1983; NSA Interceptng Gmail During Delivery; General IIR Filters; What's happening with Scala?; Interesting (But Largely Illegible) Typeface; Retiring Essentialism; Poorest in UK, Poorest in N Europe; I Want To Be A Redneck!; Reverse Racism; The Lost Art Of Nomography; IBM Data Center (Photo); Interesting Account Of Gamma Hack; The Most Interesting Audiophile In The World; How did the first world war actually end?; Ky - Restaurant Santiago; The Black Dork Lives!; The UN Requires Unaninmous Decisions; LPIR - Steganography in Practice; How I Am 6; Clear Explanation of Verizon / Level 3 / Netflix; Teenage Girls; Formalising NSA Attacks; Switching Brakes (Tektro Hydraulic); Naim NAP 100 (Power Amp); AKG 550 First Impressions; Facebook manipulates emotions (no really); Map Reduce "No Longer Used" At Google; Removing RAID metadata; New Bike (Good Bike Shop, Santiago Chile); Removing APE Tags in Linux; Compiling Python 3.0 With GCC 4.8; Maven is Amazing; Generating Docs from a GitHub Wiki; Modular Shelves; Bash Best Practices; Good Emergency Gasfiter (Santiago, Chile); Readings in Recent Architecture; Roger Casement; Integrated Information Theory (Or Not); Possibly undefined macro AC_ENABLE_SHARED; Update on Charges; Sunburst Visualisation; Spectral Embeddings (Distances -> Coordinates); Introduction to Causality; Filtering To Help Colour-Blindness; ASUS 1015E-DS02 Too; Ready Player One; Writing Clear, Fast Julia Code; List of LatAm Novels; Running (for women); Building a Jenkins Plugin and a Jar (for Command Line use); Headphone Test Recordings; Causal Consistency; The Quest for Randomness; Chat Wars; Real-life Financial Co Without ACID Database...; Flexible Muscle-Based Locomotion for Bipedal Creatures; SQL Performance Explained; The Little Manual of API Design; Multiple Word Sizes; CRC - Next Steps; FizzBuzz; Update on CRCs; Decent Links / Discussion Community; Automated Reasoning About LLVM Optimizations and Undefined Behavior; A Painless Guide To CRC Error Detection Algorithms; Tests in Julia; Dave Eggers: what's so funny about peace, love and Starship?; Cello - High Level C Programming; autoreconf needs tar; Will Self Goes To Heathrow; Top 5 BioInformatics Papers; Vasovagal Response; Good Food in Vina; Chilean Drug Criminals Use Subsitution Cipher; Adrenaline; Stiglitz on the Impact of Technology; Why Not; How I Am 5; Lenovo X240 OpenSuse 13.1; NSA and GCHQ - Psychological Trolls; Finite Fields in Julia (Defining Your Own Number Type); Julian Assange

© 2006-2013 Andrew Cooke (site) / post authors (content).

Python's sad, unimaginative Enum

From: andrew cooke <andrew@...>

Date: Sat, 11 May 2013 11:03:33 -0400

Python is about to get an Enum.  See http://www.python.org/dev/peps/pep-0435/

And it's sad.

It's not awful.  It just fails to do anything particularly well - it's an
awkward compromise whose only real achievement is not doing anything new.

What would you expect a Pythonic enum to look like?

  class Colour(Enum):

  > print(Colour.red == Colour.green)

That's about the minimum, right?  But it doesn't do that.  The above would
require new syntax, so instead you have to define values:

  class Colour(Enum):
      red = 1
      green = 1

Still, at least the mistake above would raise an error.  Wouldn't it?  Nope.
That's a feature.  If you mess up on the non-optional values then you get
"aliases".  Because that's something I've waited all my life for, while I
never make mistakes...  Or something.  The something being that they are
smoking fucking crack.

But you could just as well type:

  class Colour:
      red = 1
      green = 2

so what does Enum get you?  It provides a bit of metaclass goop to let you
iterate over values, etc.  Whoop.

So, you go hunting around in the docs to see if there's any way at all of
avoiding the need to assign values manually.  And there is:

  Colour = Enum('Colour', 'red, green')

which suffers from the same problems as namedtuples:
  - you need to repeat the class name (in a string, which your IDE is
    unlikely to check)
  - the parameters are themselves in a string, which your IDE is 
    unlikely to parse and provide in auto-complete (they can be separate
    strings, in a sequence, but that doesn't really help).

Now if two potentially useful library classes are suffering from the same
problems than isn't that a BIT OF A HINT to try make things better?  Nope.  It
just shows how important it is to not be imaginative.  Or something (crack).

And it gets worse.  What values do you think the above provides?

Strings?  That would makes sense (red = 'red'), in that it would display
nicely and is going to provide easy to debug values.  So nope.

Integers from zero?  I mean that's how Python counts indices and there's "only
one way to do it" so that's how Python counts enums, right?  Nope.

OK, so bit fields?  That way we can do cool Colour.red | Colour.green and
make the C programmers feel at home?  Nope.

Give up?  I'll tell you.  It counts from 1.  Presumably because it's really
common to use the "if not enum" idiom.  In someone's crack-addled dreams.

Like I said at the start.  None of this is really awful.  It's just lame.
It's design by committee that finds the least offensive, least imaginative,
least useful solution.

One big pile of meh.



From: Peter Norvig <pnorvig@...>

Date: Sat, 11 May 2013 11:37:40 -0700

If you don't like writing "red = 1; green = 2" etc you can just do

Colour = Enum('Colour', 'red green blue ...')

this is fucking useless

From: Bryce <bryce.culhane@...>

Date: Sat, 11 May 2013 14:55:56 -0700

whatever happened to 'There should be one-- and preferably only one
--obvious way to do it.'

Re: Enum

From: andrew cooke <andrew@...>

Date: Sat, 11 May 2013 15:12:27 -0400

I can't believe who I am saying this to... but dude, read the article before
you comment.


What would be imaginative?

From: andrew cooke <andrew@...>

Date: Sat, 11 May 2013 15:33:53 -0400

Maybe Python needs to start considering something like atoms?  That would
address the need to hde names in strings and might also provide a more
suitable value type for enums.

Is there some (new?) syntax that could give a named scope, to avoid the need
to repeat class names?

It seems like there are underlying language issues that need a more
imaginative solution...


I agree with you #nt

From: Luigi Monaco <monaco@...>

Date: Sat, 11 May 2013 22:03:37 +0200

no text

Frustration Understood

From: Ethan Furman <ethan@...>

Date: Sun, 12 May 2013 05:03:32 -0700

I certainly understand your frustrations, and I share some of them, but I feel your characterization is a bit unfair. 
(Disclaimer, I'm the author of the Enum code.)

The driving goal was to make something useful, that would meet 90%+ of the use cases out there, while allowing for 
fairly easy subclassing so the special cases could be (relatively) easily handled.

For example, the auto numbering Enum (which I like to have myself) with easy cast to int is:

     class AutoNumber(Enum):
         def __new__(cls):
             value = len(cls.__members__) + 1
             obj = object.__new__(cls)
             obj._value = value
             return obj
         def __int__(self):
             return self._value

     class Color(AutoNumber):
         red = ()
         green = ()
         blue = ()

And if you don't want it to start at one (again, something I tend to agree with, although I also understand Barry's 
feeling that enums are something rather than nothing) just take out the + 1 on the value line.

Some good feedback here

From: Nick Coghlan <ncoghlan@...>

Date: Sun, 12 May 2013 21:18:45 +1000

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.

Regarding the lack of magic in the definition syntax, that's driven
largely by the way we plan to use them in the standard library. I've
written more about the design in general at


Nick Coghlan   |   ncoghlan@...   |   Brisbane, Australia

Atoms in python

From: Jonathan Hunt <j@...>

Date: Mon, 13 May 2013 00:34:26 -0700

I'm not so pessimitic about enums in python, but I think atoms are an
interesting idea.

You can do something easily just by wrapping a string.

About "Python's sad, unimaginative Enum"

From: "Yves Daoust" <yves.daoust@...>

Date: Mon, 13 May 2013 09:05:50 +0200

I don't want to be as harsh as Andrew, but I don't love the declaration
syntax of these Enums either.


Explicit numbering is tedious an error prone, so auto-numbering is an
absolute must.


(In my understanding, the true purpose of enums is to define symbolic
values, whatever their internal representation; practical needs have called
for the support for bit-field masks, hardware-defined constants or
enforcement of other "hard-coded" values, which should remain the


I find the syntax for auto-numbering too heavy: one equal sign, two
parenthesis and a newline per item at too much to my taste (at least four
keystrokes, of which two are shifted). A single coma would be far enough
(the unimaginative way J).


By the way, some notation for compact representation of bit-field masks
could be welcome, like Mask= :5 and Mask = :5:7, instead of obscure
0x00000020, 0x000000E0 or similar.




                Yves Daoust

Re: Python's sad, unimaginative Enum

From: Duncan Booth <kupuguy@...>

Date: Fri, 17 May 2013 15:19:04 +0100

While most of what you wrote is subjective, you are wrong on one factual point:

> What would you expect a Pythonic enum to look like?
>   class Colour(Enum):
>       red
>       green
>   > print(Colour.red == Colour.green)
>   false

> That's about the minimum, right?  But it doesn't do that.  The above would
> require new syntax

No, that is syntactically valid, and it is even easy to implement
something that behaves in the way you expect, however the PEP authors
chose not to go that way (probably for very good reasons):

>>> import collections, itertools
>>> class AutoEnum(type):
    def __prepare__(metacls, name, bases):
        return collections.defaultdict(itertools.count().__next__)
    def __new__(cls, name, bases, classdict):
        result = type.__new__(cls, name, bases, dict(classdict))
        return result

>>> class Enum(metaclass=AutoEnum): pass

>>> class MyClass(Enum):

>>> MyClass.a
>>> MyClass.b

An alternative.

From: Francisco Mota <fmota91@...>

Date: Sun, 23 Jun 2013 22:08:36 +0100

If you want to work with the standard Enum and still have automatic
counting, the easiest (IMO) way is to declare an Enum as follows:

import itertools
_count = itertools.count()

class Color(Enum):
    red     = _count.next()
    green   = _count.next()
    blue    = _count.next()
    fuchsia = _count.next()

Comment on this post