No, please don't. Those are reserved for different things.

What makes that better than just using strings?

[ Edit: add more context ]

My use case for this is to map between the database and application logic.

In the example, the short string 'N' is for storage in a db column, *.NEW is for use in code, and "New" is for use to display in an UI. You don't necessarily want to persist the display or var name because you may want to rename them in the app later. IMO it's a bad idea to store display representations as data.

Instead of

    if bla in [bla, blubb, bfoo]:
      return True
    return False

you can write:

    return bla in [bla, blubb, foo]

Done! Thanks :)

Absolutely. I have not seen a factory pattern in use in ages. I think the last time was before http://dirtsimple.org/2004/12/python-is-not-java.html was around.

Oooh, check out Django - it uses them for forms (and maybe other things). I've spent far too much time tinkering with modelformset_factory, inlineformset_factory, and my personal favourite, generic_inlineformset_factory.

(As a bonus, they're quite poorly documented too. Yay!)

The idea of patenting it has roughly the same amount of hilarity.

That depends more on whether your algorithm is easily distributed. If it is, zeromq will be good for you.

I am currently using it to transfer model parameters learned on machine #1 to machine #2 where real time prediction takes place. The predictions are then sent out via 0mq to a robot controller.

The great thing of building systems with 0mq is that you just add another component without having to think too much about 'but then I will have to implement a protocol for it and HTTP will probably to slow and the request/reply pattern doesn't really fit there blabla'.

> Only one will get there first, so only one will be able to arrest the person.

Where do you buy them real world semaphores, eh?