Moderate Realism

There’s a thread over on the Python list which started a week ago as I write and is still running. The OP titled his post the provocative “I strongly dislike Python 3″ but what it really comes down to is “I strongly dislike print()”. Various people have come in on both sides of this well-worn argument.

Now, I don’t really mind futile discussions, and this clearly is one: Python 3 isn’t going to switch back, no matter how many people weigh in on the print-as-statement side. I’m in that camp myself, and when the matter was first up for discussion I had a to-and-fro with Alex Martelli on the subject which I backed away from fairly quickly. I continue to enjoy and benefit from Python regardless; I contribute to its development very slightly and very rarely; and even were I the most prolific contributor on the planet, I don’t believe that would give me any particular right to dictate design decisions of this sort. You take the rough with the smooth.

I think the side of the discussion which irks me the most is from those who are defending the print-as-function decision. Clearly there are cogent and persuasive reasons why print should be / should have been a function. No-one’s pretending that this was a decision taken randomly and for the sake of change. Or even for the sake of a foolish consistency. But if someone’s working practice involves using print a lot — perhaps in the interpreter rather than in a code editor — then the switch to the function version is clearly a burden. It may be more or less of a burden, but it involves having to do something which you didn’t have to do before. Being told that you should have been using logging or pdb or sys.stdout.write — all of which are valid tools to use in the proper place — doesn’t really make your life any easier.

So while Python 3 is now the default interpreter on my shortcut keys and I’m trying to write new code against 3.2, I still find it a pain to overcome the very long habit of, eg, print ad.find_user ().sAMAccountName. Obviously if Python 1.5.2 had had print () as a function originally, I wouldn’t find is so hard now. ;)

(As an aside I did wonder at first whether the American or some other non-UK keyboards had the brackets in some more convenient spot, but it doesn’t appear so…)

We had a blast at the London Python Dojo last night. Food, drink, and location generously provided as ever by Fry-IT (may all their contracts come in on time and under budget!) and a book for the raffle from O’Reilly (may all their titles remain in demand). While the wining and dining (or was that whining and dinning?) was in progress, Nicholas had set up a whiteboard for what-to-do suggestions. When it came to vote, some ideas were thought good but impractical for one evening, and the winner was the original suggestion: Cells.

Well I had misgivings as to whether we could grasp the codebase and get a workable solution in place within an hour and a bit, but it was great. The idea is — within the rules of the game — to pit your agents against the other teams’, trying for a winning strategy combining eating, attacking, moving, and replicating, each of which need, lose or gain energy according to certain rules. The agents can also message others on the same team to communicate, eg, the location of food or enemies. We had four teams, some with agents based on the sample code, others with from-scratch algorithms.

The clear winners were the “white” agents — Team 2 — who’d based their strategy on one of the supplied examples plus an expansion phase which kicked in only once a certain amount of time had passed and involved replicating like mad. On Team 1, we’d gone for a pacifist approach, with some of our agents as “Buddhas”, staying still and eating, the rest “Hungry Ghosts”, eating, moving and replicating. None of them attacked. FWIW, we got wiped out pretty quickly, although that did depend on how far you started from the voracious white team.

The other teams had differing strategies: explorers and eaters; or tribal warfare — which looked hilarious on-screen, as all the yellows suddenly went into warfare mode, sending each other the location of nearby enemies and flocking towards them.

Next Dojo’s in September, but EuroPython’s later this month and I’m sure there’ll be quite a few us there.

Combination of aide-memoire and Python info. If you want to return a datetime object from within a C extension, you need to invoke the PyDateTime_IMPORT macro and you need to do it without brackets and you need to do it from within your module’s import function:

PyMODINIT_FUNC
PyInit_fileutils (void)
{
  PyDateTime_IMPORT;
  return PyModule_Create (&fileutils_module);
}

This is — sort of — expressed in the current docs but because the markup uses the :cfunction: role, Sphinx automatically appends a pair of brackets to the text. Additionally there’s no indication of where to invoke the macro. I tried a couple of places (at the head of the file, somewhere in the code) before discovering that the code would at least compile without it, so I assumed that it wasn’t needed for my simple use of PyDateTime_FromDateAndTime. Until it crashed on me, at which point I went searching and found the answer (thanks, Martin).

I plan to patch the docs, at least to change the markup to use cmacro, possibly to indicate usage once I’ve got some input from more knowledgeable people.

Much fun and laughter at the Dojo last night (helped along, as always, by Fry-IT’s generous sponsorship of location, beer & pizza). Despite the name, this month’s was more of a talks session, picking up threads from previous Dojos and a couple of other random things. Went on a bit long as a result, but good fun nonetheless.

I kicked off with a talk about Pyro, which has recently announced a major version alpha release with versions for Python 2.x and 3.x. We’d discussed the possibility of enhancing our desultory Adventure Game efforts with multiplayerness and I’d volunteered to show how Pyro might be used for the purpose. Of course, the last-minute neatening-up and bugfixes I’d made before leaving the office didn’t make it onto my laptop, leaving me scrambling to correct code with minutes to spare. (Let this be a lesson to you: hg commit && hg push). Although I’d prepared a fairly tight series of examples and didn’t hang around, I still ran for 40 minutes with a few questions thrown in. (Coincidentally, as I sat down again, I had an email from Irmen de Jong, the author of Pyro, asking if I’d tried the new Pyro 4.x on Python 3.x yet. As it happens, I’d intended to do a simple comparison as part of my presentation, but I ran out of time).

Dave Kirby followed from the same angle, with a presentation about Twisted. *His* talk was hampered by laptop-to-projector issues which gave us a green screen, then a red screen, then as we were preparing for a blue screen it went green-red before Gaultier kicked the projector and we went back to white. I certainly came out understanding more about Twisted (which isn’t saying much, admittedly) and I can see why people enthuse about it so much. I’m also aware, from comments on the main Python mailing lists, that the Twisted guys have done a lot of work to file away the rough edges which result from getting low-level cross-platform networking code running.

I think Tom Dunham’s presentation was the best of the night (altho’ I’d had a glass of wine by then, which probably helped). A few dojos ago, one team had used Divmod’s Reverend implementation of a Bayesian classifier as a way to have more flexible parsing / analysis of the user input. It had worked at first, but had soon fallen apart in spite of some ingenious (read: desperate) attempts to “trick” the classifier into giving the desired result. Tom had gone away to investigate how we’d misunderstood the way in which such a classifier works. He came back with a presentation which skipped the maths (fortunately for most of us, I suspect!) and focused on the internals of the classifier, showing how our approach was hopelessly overloading the classification pools to the point where it would classify “the moon is cheese” and “the” in exactly the same way.

Jon Ribbens followed with a demo of his — now quite mature — jon.py web framework, built before almost all the other ones in common use today but still offering remarkable value for (no) money.

In spite of the late hour (gone 10pm before he started) Nicholas Tollervey, our brave organiser, gave a Lightning talk on FluidBD, which answered at least some of the questions we had about it (such as: what is it?), although it left me with the impression that it could be a Brave New World or a Interesting Curiosity.

Next time we’ll probably go back into Dojo mode proper, and with a new project to replace our slightly tired Adventure Game.

Trent Nelson has just posted to python-dev about a Microsoft-sponsored proposal called CoApp. The idea is — as I understand it — to support the packaging of Open Source s/w on the Windows platform. The current situation is quite well outlined on the wiki. It looks like a very interesting initiative and I for one hope that it succeeds.

I find exactly the issues that the author outlines on page: open source s/w is mostly *nix-oriented, naturally, and assumes the development setups which that implies. By and large, Windows ports are either best-endeavour bolt-ons or rely on Cygwin / MingW environments. Python performs rather better here with a maintained VS solution, but even there you have to do a little bit more jiggery-pokery with file locations than I’d like.

I’ve signed up for the CoApp announcments list, so let’s see what happens…