Bad Things About Pycon

This was written for a coworker who was bummed out about not being able to go to Pycon this year. The views expressed here are possibly slightly exaggerated for comedic effect.

1) Django people. They are crazy. Avoid at all cost. If you don't know why, go and find a herd.

2) It's held in the same city two years in a row and that city is never Las Vegas. I'll go to Atlanta once. Under normal circumstances, why would I want to go back?

3) You know the people you work with? Imagine hundreds of such people all in one place. Imagine seeing eight copies of yourself in the hotel lobby. Now imagine yourself getting into a fist fight with three copies of yourself. Pycon is mirrored worlds colliding with frightening results and often shards of glass in eyeballs.

4) Guido van Rossum is lazy. The year I went to Pycon his keynote address consisted of him answering questions tweeted to him on a large screen. Would it be too much trouble to write a little something up in advance?

5) Pycon is for networking and schmoozing. Don't expect to learn very much or see too many new things. It's for "pressing the flesh" and what socially awkward flesh it is!

6) All the talk about Python saving the planet (I'm slightly exaggerating) is nauseating. It's a freaking programming language. Get over it. It's not going to cure cancer, it's not going to become self-aware, and it's not going to make you live forever. Other programming languages can be nice too.

7) There are five talks you think look interesting. Four of them are scheduled at the same time. You are able to go to two of the five talks. They turn out to be disappointing and the ones you had to miss were rumored to be awesome. You watch the talks you missed on video later, at home, when they are posted. The audio and video turn out to be poor and the talks really weren't awesome anyway.

8) If you are a single guy and are looking for a cool python chick for a relationship, forget about it. There are attractive women at Pycon. However, they are always mysteriously surrounded by huge groups of smarmy looking guys. Good luck with that.

9) Hipsters. Pycon has them.

Python Question

I've been working on my game, Stones. I think I want the game engine to have something called a "future event list". I'm struggling with how to implement this.

An event consists, essentially, of a timestamp and the code you want to execute when the event happens. An event is created with all this information and then inserted into the event list. The code is executed sometime later. I'm not sure how to specify the code to be executed and how to execute it.

I'd probably like an event to consist of an object that the event is happening to (or is causing), a method to call on that object, and parameters to pass to that method. Is there a slick way to specify, store, and use those parameters when the method is executed?

One way to do it is to have every method that can be an event take an event object as its only parameter. When an event is created, it is loaded up with the object, the object's method to call, and the parameters the method will use. Essentially the event would act as the "execution environment" for the method. If you need to pass a parameter to the method, you specify that parameter in the event. When an event is processed/executed, the method is called on the object with the event as the parameter.

The above scheme seems to have some downsides. For one, you lose the method's signature (list of parameters). So, it's harder to see what needs to be passed to the method. You'd have to read the method to see what it needs. Also, you lose the ability to call the method in a "normal" way, that is, without building up an event object first.

One way to get around the two above problems is to specify a special "eventable" method for each method you want to use in an event. This method would accept an event as a parameter and then call the corresponding "non-eventable" method and pass the second method the needed parameters from the event object. This would work but it would seem to uglify the code a good bit.

Another way to do it would be to have every "eventable" method have all of its parameters be "None" by default and have the last parameter be an event that is also "None" by default. If called with an event, the method gets the values it needs from the event. Otherwise, it uses the parameters passed in. This way of doing it avoids the above two problems but each method would have to have special code to get the parameters from the right source.

So, my question is this. What is/are the best way(s) to save an object, a method on that object, and the parameters the method needs for future execution in a python program?

I'm sure one of the thousands of python programmers who read my blog will have the answer.