I feel like a sub-editor just struggling really hard to avoid punny headlines like “A Unique Experience” and “5 Unique Solutions” and so on… because last night’s challenge was to recreate the Unix “uniq” command in Python. In fact, this was chosen only after a tie in the first round of voting giving us a top 4 rather than a top 3 and a triple-tie for second place in the second round, although with one clear winner. (Otherwise I was going to have to move onto a Single Transferrable Vote round).

It was nice to see quite a few new faces, 6 or so first-timers and several who haven’t been for a while or who have been only once or twice. Plus, of course, the old familiar faces. Fry IT continue to host us generously, including ordering artisan pizzas with enormous slices. And O’Reilly came across as always with a book for the giveaway at the end.

Most teams went for a fairly straight solution, one of them managing to carry a TDD approach pretty much throughout. One team had grander ambitions for field selection and datatype conversion, but their solution ended up on two different machines with not enough time to merge properly. I was a little surprised that no-one used itertools groupby, which is pretty much advertised as a drop-in for uniq.

You can see a few photos retweeted at the @ldnpydojo account. Back again in January, probably on the second Thursday. But watch the python-uk mailing list and @ldnpydojo for announcements.

This is the third time that PyCon UK has organised a track especially for educators: really, for Primary & Secondary teachers, rather than for University lecturers. The first, a couple of years ago, was small, essentially a few hours within the main conference. The second, a whole Saturday last year, suffered from a belief that teachers would be too busy during the week and would prefer to come at the weekend. (In fact it seems they’re happy to get a day out from school on legitimate business such as learning about Python). This year we had upwards of thirty for the whole of Friday, students as well as experienced teachers.

You can read about some of the activities on offer and what they got out of them on their blogs and elsewhere. What I want to talk about is what I got out of it. I don’t think I learned anything absolutely new, but certain things were brought home to me more clearly.
I think that, as hackers (in Eric Raymond’s sense of that word), we expect teachers and pupils alike to be on fire with enthusiasm for programming, agog to learn more and to advance in this amazing world, and skilful enough to appreciate the subtle nuances and elegant constructs of the Python idiom. And we expect their schools to be 100% behind them, facilitating their initiatives, and supporting their ideas for learning in the 21st Century.

There surely are such people and institutions out there. But the picture painted by the teachers at PyCon UK was quite different. IT Administrators – whether school or county – can be restrictive in the extreme: disallowing access to the command prompt, enforcing bureaucratic processes for installing new packages, and limiting network access. At the same time, pupils may not be the excited and engaged proto-hackers you might have hoped for; they may have real difficulties with even the simplest of programming concepts. And the teachers are … teachers: people whose daily life is spent charting a course through the administrivia of modern-day schools, managing classrooms full of underappreciative pupils, and struggling to master for themselves some of the concepts they want to pass on to their pupils.

Like many in my situation, I started programming when I was 12, initially on my engineer Father’s programmable HP calculator and then, like so many others, on a BBC B. And I genuinely can’t remember a time when programming wasn’t intuitive. Of course, I’ve learnt and improved over the years. Of course there were things I didn’t understand; there still are. But the basic ideas of programming have always come easily. And I can find it a real challenge to put across concepts which are so very basic and whose explanation you’ve never needed to people to whom they don’t come naturally: to do the job of a teacher, in fact.

But that’s what each of us had to do for most of the teachers at PyCon UK and that’s what they have to do for most of their pupils. Even those teachers who have some experience in programming can struggle to visualise the solution to a more complex problem. To make matters worse, Computing is one of those subjects – like Music, perhaps – where a small number of the pupils can be streets ahead of the rest of the class. And maybe of the teacher.

On the Friday afternoon, after a morning of workshops, we had a Dojo-like session where teachers called out ideas for projects they’d be interested in pursuing with help from developers, and we developers attached ourselves to a group to offer advice. The group I joined was somewhat decided for me as one of the teachers was asking for help with an A2 project involving using a relational database to produce a simple room-booking website– and since my day job involves relational databases, I was pushed to the front to help a group of eight or so teachers.

In the discussion which followed, it became clear that, not only were many of the group of teachers hazy on the ideas of relational databases, but also of dynamic websites, plus the pieces of Python needed to pull those together. Another developer helpfully jumped in to propose Django, which brings us to the point I started to make above. Django has a good tutorial with a useful get-you-started admin mode, is well-documented, and has a strong and helpful community. But it requires a big level of buy-in from the pupils and, especially, from the teacher who will have to be able to help them.

“But there are forums,” you cry, “and mailing lists, and stackoverflow answers, and books, and lots of documentation”. And there are. But I was talking to teachers who have to fit a project like this into the structure of perhaps one or two classes a week plus homework among everything else. And something like Django is a big overhead. “But it’s easy!” It‘s not bad , if you already know what you’re talking about, or have unlimited time to play around and throw projects away. But, for this small project alone, I was having to pull together a headline course on relational databases and your possibilities using Python, with or without non-stdlib modules , plus the same thing for web programming, plus all the Python bits to make it all work. It was humbling to realise how many obstacles a teacher has to overcome to fulfil even the basics of the current computing curriculum.

As a proof-of-concept, I jotted down some notes on the spot, and ran up a couple of modules using sqlite and bottle (since it’s a one-file import which makes it easier to smuggle past restrictive installation régimes). The results are on my github.

During the Sprints on Monday (and on the way home) I decided to take it further, and to dust off an idea I had last year and which I hadn’t really pursued: One Screenful of Python. In last year’s Education track, I’d understood that one screenful of code was about right for one classroom session. So my idea was to produce useful, engaging, readable, snippets of Python which would fit, roughly, onto one screen and would produce an interesting result and illustrate some useful points of the Python idiom or of programming in general. It’s hosted in a github organisation.

It was quite clear that the project of building a website for room bookings using a relational database wasn’t going to fit on one screen even with some code gymnastics, which would in any case have defeated the pedagogical purpose of the exercise. So I restarted and produced a one-module project, built up over 13 steps, each building on the last (so a code-diff tool will produce a useful comparison). The result is in its own repo within the One Screenful organisation.

The code should run unchanged on 2.7 and 3.x; it should run cross-platform, especially targetting Windows & Raspberry Pi as they’re most likely to be found in the classroom; and it should work with the stdlib alone. These restrictions are an attempt to reduce possible difficulties teachers might face in getting it up and running. Sticking to the stdlib obviously precludes handy tools like Bottle (or your other lightweight web framework of choice), SqlAlchemy (or your ORM of choice) and whatever else might be useful. But it does simplify things. (pip install on Python 2.7 on Windows anyone ?).

But the most difficult restriction was in writing code which would be understood by A-level students. I’d struggled valiantly to pull back my hand and write simpler code. And then a teacher who kindly gave me feedback said that she thought the more able among her pupils might be able to cope with the code! This is the nub of the issue: the pupils who are gifted in this area can head off into the distance and work up full-stack Django apps from the online documentation and StackOverflow questions. But the run-of-the-mill average students need things to be kept simple to get them started.

If I have the time I’ll probably do a Git branch which will rework the final codebase in terms of, say, Bottle and SqlAlchemy. I don’t say that learners shouldn’t know about these things: they certainly should. I just think that every tool you add to a stack, no matter how useful, adds complexity. And if someone is a beginner, it might be better to stick to standard stuff. (I recognise that this is not a very strong argument since the code needed to manipulate SQL without an ORM is relatively verbose; likewise, using the built-in WSGI support). I also considered an approach of using git tags rather than the separate directories for the progressive disclosure of of the codebase. But, although it’s a neat idea, it’s an additional complication to cope with in the classroom.

So what did I get out of the Education Track? Well: that what many teachers need is simple code, easily installed, runnable without complications on different platforms. I’d like to be able to help, but I have commitments of my own which prevent me from easily giving much time to direct help in a classroom. But providing suitable code and advice is something I can do.

Someone I meet only in Coventry mentioned in the hallway in this year’s PyCon UK that I’d not written about anything this year which he could comment on when he met me there. And indeed I was surprised to realise that my last post on this blog was about last year’s PyCon UK! I know I’d had several ideas for what to blog about, but clearly those ideas never became a reality.

As I pointed out in that year-ago post, every PyCon UK charts its own course for me each year. This year I was heavily involved in the Education & Kids’ tracks across the road in the Simulation Centre. In fact, apart from quick visits to the dining hall for food, I hardly interacted with the main conference at all throughout Friday and Saturday. As I tweeted at the time, the first talk I attended at the conference proper was the one I was giving first thing on Sunday morning!

Others have already done so, but I’d like to give tons of credit to Nicholas Tollervey who organised and ran the Education and Kids’ track (as well as giving a talk at the conference proper on turning footfall data into music). This involved liaising with schools and teachers for over 30 teachers to be able to attend PyCon UK as part of their Professional Development, in some cases assisted by money (generously provided by the Bank of America) to help pay for classroom cover. The Bank of America also paid for the venue, while the Python Software Foundation provided money to cover travel & accommodation. And then there’s the job of organising for 70 kids to come and have some experience of programming in a supportive environment. Those who only know Nicholas as a developer and organiser-in-chief of the monthly London Python Code Dojo may not be aware that he was a professional tuba player and, significantly here, a Secondary School teacher. This (I assume) gives him an insight into what will give the most benefit to the teachers and youngsters attending.

I hope to write a separate blog post on the Education slice of the conference on Friday. (If only to ensure that I have at least two blog posts to my name this year!). The Saturday event for children was certainly well-attended. We were over there not long after 7am setting up chairs, tables, RPis, keyboards, mice, screens and a *lot* of power cables to keep 70 youngsters occupied. Because of the numbers, activities were split over two large rooms plus two smaller rooms for specific activities. There were guided sessions on Minecraft, using the Pi camera module, and using PyGame plus a fair amount of freeflow action, mostly involving Minecraft. At the end was a show-and-tell where at least some of the various projects were showcased.

The Raspberry Pi Foundation Educational Outreach Team (or whatever they’re called) were there on both days, and in fact throughout the conference including the sprints on Monday. As well as running workshops in the Education track, they also provided a Model B+ Raspberry Pi for each of the youngsters attending, and gave talks and keynotes speeches at the main conference.

I attended relatively few of the talks at the main conference. I did like the gov.uk team’s presentation on their approach to using Flask to implement wizard-style forms (a project codenamed “Gandalf” apparently!) and which they hope to be able to open-source. The lightning talks I did get to see (ably compered as usual by Lightning Talk Man) were interesting; and one of them was even using my active_directory module. Another blog post from me in the making there, I hope.

The one very obvious aspect of the PyCon UK this year was the numbers. And, as a result, the queues, especially in the dining hall. Even my own talk – on the fairly niche subject of Core Python Development on Windows – was fully attended, presumably as a result of refugees who couldn’t fit into other talks and were desperate for somewhere they could at least sit down. It’s nice problem to have: to be too popular; but I imagine the organisers are looking hard at arrangements for next year.

I stayed for the sprints on Monday and so was looking for somewhere to eat on Sunday evening, traditionally the least organised of the PyCon UK evenings. I went looking with Conor & Ben for somewhere to eat in Coventry on a Sunday evening. With limited success. (We did eventually find somewhere open). I spent a pleasantly quiet rest of the evening with a pot of tea in the hotel bar, and chatting to Giacomo about this and that.

Monday was sprints, and although I was available to help people get started on core dev work, I was actually sprinting on my own Screenful of Python idea, of which more in a later post.

Every PyConUK has a different feel to it. By which I mean: I chart a different course through the weekend each year. Of course, the specifics of the conference itself change each time, too: the talks being given, the rooms being used, the people there, the special events or tracks being offered; all those things affect the feel of things too. But, as the ever energetic Zeth (”Really I should call this ZethConUK”) pointed out at one of the several opening addresses: this is a community conference; it is what you make it.

This year I’d committed to being a session chair for an hour and a half in one room on the Friday afternoon. Being a session chair means you’re going to be listening to three sessions, whether or not you’re inherently interested in the subject matter. In my case matters were made more interesting by a misunderstanding by one of the speakers who mistakenly took another speaker’s slot. At the exact same time that the Wiki was out of action after over-zealously shutting down when detecting an IP-bomb. (ie all the people at PyConUK on the *same* Nat-ted address all trying to access the schedule at the self-same time). This meant that I couldn’t check the timetable and I had to believe the quite-certain speaker’s version of events. The thing was resolved amicably and we moved on.

My own talk had been in the very first slot of the Fri afternoon sessions and nobody walked out or evidently fell asleep so I’m willing to judge it successful on that basis!

Following on from last year’s “Teachers’ Track”, the indefatigable @ntoll [actually: very fatigable as we saw on Monday] had organised both an education track on Saturday and a Raspberry Jam on Sunday, assisted in the latter by “Mr Raspberry Jam” himself: Alan O’Donohoe. There are pictures and videos of both around the web, for example here and here.

This year we had bigger rooms, which worked for me. I slightly missed the Tweetstream which used to be projected in the [this year’s] “HP Room” but Twitter traffic didn’t seem that great when I checked so maybe the Twitter-buzz is tailing off, or at least plateau-ing.

As always, the chance to meet people, the evening meals and drinks, looking around historic Coventry, all the not-conference things add to the occasion. The Ibis hotel is perfectly pleasant and reasonably priced (and effectively on-campus for the conference). The staff at the Technology Centre are helpful and friendly and competent; several times this and previous years I’ve witnessed the dining room staff go out of their way to try to accommodate someone’s needs even when, for whatever reason, they haven’t been given advanced notice.

My particular take-home idea from talking to teachers at the Education track was the idea of “One Screenful of Python”. I’ve started a Github organisation but I haven’t yet fleshed the thing out fully. The basic idea is that programmers would like to contribute to helping teachers out, but don’t necessarily have the time or flexibility to go into schools directly. But teachers would be helped by having a self-contained piece Python code which does something interesting. A screenful is the right size to put in front of a class and go through in the course of one lesson. Don’t know if it’ll come to anything, but it’s worth a try.

Anyway, big thanks as always to John Pinner and the PyWM team and everyone else who helped. (Hat-tip here to Peter Inglesby who very ably coordinated speakers and session chairs). I enjoyed it and I look forward to next year.

PS There are links to write-ups and photos over on the wiki.

An unwieldy title for a great event.

Everything came together on Sunday at this year’s PyConUK in the TechnoCentre in Coventry for the 3rd year running. We were lucky enough to get Bank of America to sponsor a Raspberry Jam and lucky enough that Alan “Jambassador” O’Donohoe was around to lend his manic energy and unique style.

Despite the relatively short notice we were able to give, we had 25 youngsters plus their parents helped by as many Python developers from the main Conference plus some of the teachers who’d come for Saturday’s Education Track. I’ll link to some of the photos that were taken when they’re posted up. But it’ll be clear to you just how much manic energy was involved and how much youthful mayhem was harnessed.

We had people bringing robots and Python-controlled helicopters; we had children bringing Minecraft-inspired ideas and wackiness; we had people controlling LEDs; we had Scratch and Minecraft and pure Python; some people brought their own Raspberry Pi’s and other people used the ones we’d supplied; some of the parents caught the bug and were coding along with their kids; sometimes it was the other way round.

At the end, a group of three girls (and we had probably a 50-50 mix) went over to present a Lightning Talk to the main conference itself, showcasing their Minecraft-powered UFO.

Overall I think we can count our first foray into Raspberry Jamminess an success. We’re tremendously grateful to Bank of America whose sponsorship enabled us to use the excellent Simulation building as a completely separate space for what was, in effect, a subconference. I hope that it’s inspired people to run their own version of a Raspberry Jam, and that it’s given kids and their parents a flavour of what you can do with a little creativity.

UPDATE: There are photos here

Those of you who don’t frequent the London Python Dojo wouldn’t appreciate the in-joke behind the laughter which greeted the selection of “20 Questions” as the challenge for last night’s Dojo. For months Nicholas Tollervey, the main Dojo organiser, has seeded the list of Dojo suggestions with the idea of implementing a simple expert system where the computer maintains a taxonomy of objects and tries to identify an object of your selection within 20 guesses by a process of elimination. It’s become a source of humour that Nicholas has to offer the same explanation every month and that the idea is never selected as the challenge du jour. Well last night it was.

And I admit that it was much more involved than I had thought it would be. I honestly thought we’d be done in 10 minutes and looking for ways to fancy up the interface or whatever. How wrong I was! The teams split between a tree-based structure with nodes holding questions & answers and yes/no pointers; and a matrix of questions which attempted to eliminate possible objects with each question. Getting the exact looping and yes/no pointing right is harder than you might expect, especially when you’re pressed for time and you have a team of five people to consider.

We were hosted, not for the first time, by Mind Candy (of Moshi Monsters fame) in their gorgeously child-friendly offices with Mind Candy local Al Broomhead as MC. And, as always, O’Reilly provided a book for the end-of-evening raffle. I’m consistently impressed by O’Reilly’s readiness to support us: I imagine it doesn’t cost them loads to give away a book a month, but they could so easily turn us down and they continue to provide, month after month.

There have been discussions, on-list and in private, about various aspects of the London Python Dojo and the organisers have various ideas in mind, but we’re not planning to do anything drastic to the current approach. (Although our setup means we can easily experiment with something if we want). Our main idea is to emphasise our status as a beginner-friendly forum where everyone can and should get a chance to code in Python even if they’re a newbie amongst experts. I’m glad to say that, in our team yesterday, everyone got a chance to code, however lightly.

Beforehand, @ntoll gave a talk about the upcoming PyConUK and particularly about the education track, encouraging people who know or are teachers and who know or are children to come along to these special aspects of the conference. I also gave a lightning talk about the socio-political challenges in Python core development — and about how people could and should contribute.

[The title of this post refers to a commonly-asked question shouted out from the audience as the various teams were demo-ing their approaches. Demonstrating necessarily involves going through as a series of “Is it …?” “What question could I ask…?” prompts and this one turned out to be a popular question, especially if the object in mind was a Robotic Catfish!]

A long time ago (I don’t remember exactly: years) I subscribed to the Python distutils-sig mailing list. And then I unsubscribed because it was noisy and not terribly fruitful.

Now, chasing down a Windows-related pip issue, I’ve come across it again and discovered that there’s a shed-load of useful work going on there. I had no idea that distribute (a fork of setuptools) & setuptools had [re]merged as of setuptools v0.7, and I’d lost sight of the many PEPs on naming, versioning, distribution formats and the like. I still haven’t worked out which is which, but at least certain of them seem to have reached the stage where they’re the point of reference for other discussions — not discussion points in their own right. There’s an initiative to get pip into the main Python distribution — which I also had no idea about.

I’m especially happy to see Paul Moore holding up the Windows end of things in discussions — thanks, Paul! Despite our both being UK-based [*] and Windows types and long-term Python users, we’ve never actually met AFAIK.

I’ve resubscribed now and I hope to be able to contribute in some small way.

[*] I’m fairly sure — and he did recently make a reference to Gunga Din, which is something I’ve never heard outside this country.

[tl;dr photos here]

Last night’s London Python Dojo was held, for the first time, at the very spacious Canary Wharf offices of the Bank of America. They’re big users of Python and, as we were told in an brief introductory, were keen to give something back to the Community.

They certainly did it in style. Their main reception is about the same size as Ealing Common. The meet-and-greet bar area where we had Pizza on classy platters & Beer served by bar staff is not much smaller than the whole of the offices of Fry IT, our long-standing default hosts. And the area below where a few of us gathered feels like a swimming pool with a long slide-like flight of stairs leading down. The function room where the main business of the evening was transacted was spacious with large tables (and *lots* of pencils!).

The guys at BoA had really done their prep work: power strips were already in place and every possible laptop-to-screen adapter was available. (For those who haven’t done this kind of thing: there’s *always* some kind of mismatch between a screen which can only take DVI-I and a Mac user who doesn’t have the Mini-HDMI-to-DisplayPort adapter. Or whatever: I use Windows which never has these problems ;) ).

As well as the friendly intro from one of the BoA guys, we had an enthusiastic lightning talk on Bitcoin from Sam Phippen (who comes in from Winchester or Bristol for the Dojos!). With over 30 people present, we had about 15 suggestions for the evening’s challenge, including old favourites (How does 20 Questions work, Nicholas?) and new ideas, some around the theme of banking. After the usual two rounds we settled on Steganography and made use of the generous table space (and pencils) which our hosts had provided.

The results are on Github (or will be, depending on when you’re reading this) as pull requests come in and are honoured. In short, two (three?) teams went for piggybacking on image bits; two teams (including the one I was with) encoded bits in the extraneous whitespace of a text document; and the last team tried to use the Python’s indentation to carry information in some way which I couldn’t quite understand at the time. I think that every team bar the Python-indentation one had a working result[*]; ours even had unittests!

FWIW my first idea for our team was to encode the characters in Morse code (using spaces & tabs as dots & dashes). We finally settled on binary but I still think Morse would have been cooler — and we could have played the message out as a midi file for extra points!

Of course at the end we had a draw for O’Reilly’s usual generous contribution to proceedings along with an added bonus: an historical map of programming languages. Appropriately enough, the book was won by Sal who’d been the driving force behind Bank of America hosting the Dojo this month.

Next month we’ll probably delay by a week to come in after Europython. Not sure where we’ll be yet, but follow @ldnpydojo or look out on python-uk.

And, of course, big thanks to Bank of America for being our hosts this time round.

TJG

[*] And they may have got things working after a live “Aha!” moment by Al who was demo-ing. [UPDATE: Al was actually in another team per his comment below; so many teams, so short a memory span…]

(Background: I’ve recently and less recently worked through a couple of issues with Python’s Ctrl-C handling under Windows. These required me to dig into the corners of Python’s signal-handling mechanism as interpreted on Windows. This post is something of an aide memoire for myself for the next time I have to dig.).

Signals are a Posix mechanism whereby User-space code can be called by Kernel-space code as a result of some event (which might itself have been initiated by other User-space code). At least, that’s the understanding of this ignorant Windows-based developer.

For practical purposes, it means you can set up your code to be called asynchronously by installing a signal handler for a particular signal. Lots more information, of course, over at Wikipedia. Windows (which is not short of native IPC mechanisms, asynchronous and otherwise) offers an emulation of the Posix signals via the C runtime library, and this is what Python mostly uses.

However, as you’ll see from the Python docs Python doesn’t allow arbitrary code to be called directly by the OS. Instead, it keeps track of what handlers you’ve set up via the signal module and then calls them when it’s got a moment. The “when it’s got a moment” means, essentially, that Modules/signalmodule.c:PyErr_CheckSignals is called all over the place, but especially is called via the eval-loop’s pending calls mechanism.

So what does this mean in term’s of Python’s codebase?

* The heart of the signal handling mechanism is in Modules/signalmodule.c

* The signal module keeps track in a Handlers structure of the Python handlers registered via the signal.signal function. When the mechanism fires up, it pulls the appropriate function out of that structure and calls it.

* Python registers Modules/signalmodule.c:signal_handler with the OS as a global signal handler which, when fired by the OS, calls Modules/signalmodule.c:trip_signal which indicates that the corresponding Python signal handler should be called at the next available point.

* The signal can be delivered by the OS (to the internal signal_handler function) at any point but the registered Python handler will only be run when PyErr_CheckSignals is run. This means that, at the very least, the Python signal handlers will not be run while a system call is blocking. It may be that whatever caused the signal will have caused the kernel to abort the blocking call, at which point Python takes over again and can check the signals. (This is what happens at points in the IO read/write loops). But if some uninterruptible device read hangs then Python will not regain control and no signal handler will execute.

* The main eval loop will check for raised signals via its pending calls mechanism, a C-level stack from which a function call can be popped every so often around the loop. The trip_signal function (called by the global signal_handler) adds to the queue of pending functions a wrapped call to PyErr_CheckSignals. This should result in the signals being checked a few moments later during the eval loop.

OK; so much for the whistlestop tour. How about Windows?

Well, for the most part, Windows operates just the same way courtesy of the C runtime library. But the signals which are raised and trapped are limited. And they probably resolve to the more Windows-y Ctrl-C and Ctrl-Break. I’m not going to touch on Ctrl-Break here, but the default Ctrl-C handling in Python is a bit of a mixed bag. We currently have a mixture of three things interacting with each other: the signal handling described above (where the default SIGINT handler raises PyErr_KeyboardInterrupt); the internal wrapper around the C runtime’s implementation of fgets which returns specific error codes if the line-read was interrupted; and some recently-added Windows event-handling which makes it easier to interrupt sleeps and other kernel objects from within Python).

That really was quick and I’ve brushed over a whole load of details; as I say, it’s more to remind me the next time I look at a related issue. But, hopefully it’ll give other interested people a headstart if they want to see how Python does things.(Background: I’ve recently and less recently worked through a couple of issues with Python’s Ctrl-C handling under Windows. These required me to dig into the corners of Python’s signal-handling mechanism as interpreted on Windows. This post is something of an aide memoire for myself for the next time I have to dig.).

From time to time, the idea of a standard Python “Enum” object is raised on the Python lists. You know the kind of thing: a lightweight means of mapping numbers to labels so you can do set_colour(Colours.red) without having a long module of manifest constants or magic numbers lying around all over your codebase.

It all sounds very straightforward, and Barry Warsaw had an existing module which seemed like a fairly good starting point, so PEP 435 was started and it all looked like it was just a formality.

Now, literally *hundreds* of mailing list posts and endless, endless threads later, GvR has just pronounced his approval of the PEP and it’s good to go.

If you — like me — thought “this one won’t be controversial”, then just point your search engine of choice at mail.python.org/pipermail/python-dev and look for “enum” or “435″, or just look at the archive for May alone (which only represents the final few days of details being thrashed out) to realise just how much discussion and work is involved in what appears to be quite a simple thing.

Of course, part of the problem is precisely the fact that the idea is so simple. I’m sure most people have rolled their own version of something like this. I know I have. You can get up and running with a simple “bunch” class, possibly throw in a few convenience methods to map values to names and then just get on with life. But when something’s got to go into the stdlib then it all becomes a lot more difficult, because everyone has slightly (or very) different needs; and everyone has slightly (or very) different ideas about what constitutes the most convenient interface.

And there’s always the danger of the “bikeshed” effect. If a PEP is proposing something perhaps quite fundamental but outside most people’s experience, then only people with sufficient interest and knowledge are likely to contribute. (Or argue). But an enum: everyone’s done that, and everyone’s got an interest, and an idea about how it should be done.

But, bikesheds aside, I’m glad that the Python community is prepared to refine its ideas to get the best possible solution into the standard library. As a developer, one naturally feels that one’s own ideas and needs represent everyone else’s. It’s only when you expose your ideas to the sometimes harsh winds of the community critique that you discover just how many different angles there are to something you thought was simple.

Thankfully, we have a BDFL (or, sometimes, a PEP Czar) to make the final decision. And, ultimately, that means that some people won’t see their needs being served in the way they want. But I think that that’s far preferable to a design-by-committee solution which tries to please everybody and ends up being cluttered.