The Dojo Board

[Pictures courtesy of Tom Viner]

The February 2018 London Python Dojo was hosted by SohoNet to whom we're grateful not just because they hosted, but because they stepped up at short notice when our original venue had to withdraw. It was nice to see quite a few of the SohoNet team at the Dojo. Of course, this was all courtesy of veteran Dojo cat-herder Tom Viner who works there at the moment and arranged everything on the day and beforehand. (And who also won the month's book from O'Reilly who have donated generously to us every month for the nearly 10 years that we've been running this Dojo).


The atmosphere was great as usual, and it's good to see a nice mixture of old hands, semi-regulars, and newcomers come together. Our Patented Voting Method which, together with the Team Numbering System, surely deserves its own Wikipedia page, raised a few laughs as usual. Plus some confusion - also as usual.


I'd offered to give a Lightning Talk about my Dojo Board framework. And I put an activity on the ideas board to build something (anything!) to make use of it. This activity tied in the voting with "Yet Another Trump Tweeter" [not actually called that] and Tom very kindly applied the cat-herder's tie-breaking prerogative to declare that my Dojo Board would be the activity du soir.

First, a little background about the project. At one time it was reasonably common for people propose a challenge for the Dojo which had a board-game flavour to it: Battleships, Noughts-and-Crosses, Connect4, Boggle, Word Search, all those kind of things. They're well-understood or easily-explained challenges which fit nicely inside our hour-and-a-half of coding format.

The Dojo format is fairly open and if a team wants to focus on the mechanics of a board structure, then that's up to them. But often, they really want to work out the gameplay of noughts-and-crosses or which search algorithm will apply best to Boggle etc. But they get bogged down in agreeing a common structure for the board and how to display it.

So, one Dojo about three years ago, we decided that the challenge of the day would be precisely to create a board framework which could be used in future Dojos. I don't remember the outcome, although I don't think that any of the offerings was compelling, but I got interested in the idea afterwards, hacked on it a bit, dropped it, let it gather dust, picked it up again recently and produced something usable with tests and everything!

It's on Github so you can view it, clone it, fork it, raise Issues, send Pull Requests and so on. The main idea is that it be a useful framework where your challenge is board or tile-based but where you don't care about the board mechanics.

Highlights include:

  • n-dimensional (anything from 2 upwards)
  • any or all dimensions can be +inf, that is: they all start from zero but can be infinite to the right.
  • standard Python indexing for get/set/del: board[0, 0] = 'X'
  • boards can be sliced from other boards, eg to allow a visible viewport on a wider -- possibly infinite -- landscape
  • useful functions to find neighbours, detect edges and corners, follow lines
  • simple text output for 2-d boards

You can see the full README and, of course, read the code.

Last night was the first time it was used in earnest, even by me! I'd put a fair bit of thought into the design, conscious of the kind of requirements which board/tile games bring, but I'd never actually used it. Yesterday's challenge was an open one: use the Board framework to do something. And there was definitely variety between the 5 teams.

One team did a Minesweeper clone; one ambitious team used the infinite dimensions to generate a scrolling(ish) land/sea text map; our team managed a maze solver; someone did Connect4; the other team did Battleships. I was pleased to see that, by and large, the framework was useful and usable. There were a few Issues/PRs raised during the evening, which is good. A couple of people mentioned possible improvements, and I implemented a corner detector when our team needed it! (Open Source itch-scratching at work).


I made a few changes on the way into work this morning based on some of the feedback from yesterday: neighbours can now ignore diagonals; draw now accepts a callback which defaults to str which allows the caller to, eg, hide or obfuscate board elements according to their state (think: Battleships); and iterline can now be limited to a number of steps (this one, again, from the Battleships team).

Some things I plan to include, having seen a few struggles yesterday are (in no particular order):

  • itercorners
  • iteredges
  • iterhorizontals
  • iterverticals
  • iterdiagonals

Something which I added relatively late in the day, but which gives a real boost, is the simple text-grid output. It's not rocket science (although it does a little bit of work to get even column sizes) but it's just the kind of thing which you tend to leave to the end in a Dojo and then get flustered trying to work out the order of iteration and the combination of "+"/"-"/"|" characters in the right places.

So I'd also like to implement a .paint method which produces a PNG and, like .draw, uses a callback to request an image for each data item (cached, of course) to draw inside the corresponding cell.

But all that will have to wait because tomorrow I'm helping out again at the Turing House Coder Dojo in Teddington in the afternoon, and then running a robotics workshop for our club's PiWars entry in the evening. So I'll be a bit busy...

PyCon UK 2017

I recently returned from PyCon UK 2017 which took place in Cardiff from Thursday 26th to Monday 30th October. There were about 900 people throughout the 4 days of the conference including teachers attending a Picademy; young coders attending a Code Club, a Raspberry Jam and a micro:bit show-and-tell; data scientists attending a PyData track; those attending a Django Girls session; and everyone attending the conference proper.

tl;dr I really enjoyed it. I got the right amount out of it without burning out; I had interesting conversations with people; I picked up a couple of useful ideas for work; and I enjoyed helping the teachers, the young coders, and anyone else who asked me for advice or input. On Monday I was happy to be sprinting on my networkzero module with some other conference attendees who'd seen my talk on Saturday and interacting with the education crowd, especially the Mu maintainers and Ben Nuttall.

After last year's PyCon UK, I'd told myself that I'd definitely make an effort to help with the organisation of the Conference in some capacity. But, with one thing and another, I didn't put myself forward until the end of August. Of course, by that time, onboarding a volunteer means a lot of explanatory work on the part of the team so I was gratified when Peter asked me to pick up some of the administration of the Financial Support scheme. I also joined the organisers' Slack and was able to contribute to the discussion around the Lightning Talks bucket scheme (of which more later).

One area I'd particularly wanted to improve was communications before and during the Conference. Communication is hard: no matter how much effort and goodwill, some people miss all the notices & signals you give out and are disappointed or upset. There was an unfortunate storm in a teacup a few weeks before the Conference when someone -- having checked the website -- Tweeted that it was a shame there had no been no Financial Aid scheme. In fact, there was a very generous scheme and we were able to help quite a few people otherwise couldn't have come. But applications had closed and the details of the scheme had been removed from the website. It was all sorted out but it goes to show how easily misunderstandings can arise, even with goodwill.

I volunteered to rework the front page of the PyCon UK website in the days leading up to the Conference to include the practical information which people need when they're planning their trip (or actually at the Conference). In the course of the discussions around this, the idea of a Zen of PyCon UK arose, loosely inspired by the Zen of Python. I put something together which was tweaked by the others. And so it was that I found myself on stage, introducing the "Zen" at the opening session of the Conference [Photo by Mark Hawkins].

You can see the schedule of the conference itself with links to slides where they've been made available. Depending on when you're reading this, you should also be able to see many of the talks on the PyCon UK Youtube channel. What isn't perhaps so obvious is the tremendous amount of work going on behind the scenes before, during and after each day to make all that happen. As Daniele pointed out in his closing address, it was so common to have someone say "I can do that" whenever an issue arose. And aside from those occasional issues, there were just the everyday, ongoing work: Chloe organising the Registration Desk all the time she wasn't chairing a session (or being the Right Sock in Friday's Lightning Talks); Owen managing the Lightning Talks buckets and the Session Chairs; Alex printing out hundreds of copies of the schedule every day; Kirk organising the Board Games evening (and being the Left Sock); Nicholas with help from Tom and myself, organising the Thursday Dojo; volunteers turning up to chair sessions in any of rooms we were using; the micro:bit Foundation teams organising the the micro:bit sessions; the Raspberry Pi Foundation teams organising the teachers' 2-day Picademy event and the Saturday Young Coders' day; Tim organising video & sound recording in every room and training others to do the same; all the work done beforehand by Owen and Kristian to bring the new UK Python Association into being; the professional photographer and stenographers who brought their own expertise; the creche organisers; loads of people whom I've forgotten or didn't even know about because they just did their job and got out of the way. And behind everything, Peter & Daniele keeping everything running smoothly, liaising with the excellent City Hall staff.

The message of the Conference was: enjoy yourself and make sure others enjoy themselves. Be friendly. Be welcoming. Talk to people you don't know. Step into discussions you might otherwise have skirted because you can be sure you won't be excluded. Even the gift to speakers was welcomed: a pair of Python-themed socks. Amusing, practical, and universal: everyone can wear socks.

At some point someone had posted a message of thanks to the organisers. I realise it's somewhat gauche to quote my own reply here, but I'm going to, because I think the point I'm making is important:

No matter how trite it sounds, it would be no use our standing up there and saying "Please be welcoming. Please be respectful" if you all had other ideas. The atmosphere of the Conference is the result of the agreement of everyone that this is how it should be. And that's a great testament to the UK (and wider) Python community. [Tim Golden on Slack]

So many people have said -- on Twitter, on Slack, in person -- that they felt welcomed, that they thought PyCon UK had something special. There were several talks around a growing awareness of Mental Health and the need for a greater inclusivity. I think many people were surprised to hear Chloe -- whose cheerful enthusiasm and occasionally quirky humour were the first thing you encountered at the front desk -- explaining how PyCon UK had changed her life. Arriving at her first PyCon two years ago in Coventry, she was hugely nervous and didn't know how she'd manage to interact with other people. By the end of that conference she was so much more confident that she put herself forward for the organising committee for the next PyCon UK.

Of course there were keynote speakers, talks, workshops, and lightning talks: the bread and butter of the Conference. I picked up useful information for Big Data handling, consuming public transport APIs, making use of Postgresql and other bits and pieces, all of which will be helpful to me at work and elsewhere. Add to all that the "Hallway Track" where you just find yourself in fruitful conversations with people in between times, in the dining hall and so on.

The 5-minute Lightning Talks have always been a popular slot at the end of each day of the conference. This year, rather than just have people sign up on a whiteboard which tends to favour those in the know, we offered a bucket lottery where 5 cards would be pulled out of each of two buckets each lunchtime. One bucket was for first-time speakers, the other for everyone else. This worked well and we had the usual wonderful variety of subjects, including Python as a model sailboat controller, baking brownies, how to give good talks, a guide to saving someone's life, a guide to Mental Health First Aid and many others.

Well this is longer than I'd intended, and there is so much more that could be said, but it's difficult to capture the atmosphere and the enjoyment without having being there. Even now there's still a background buzz around how this year turned out and what we might do even better next year. I understand that there'll be a feedback form fairly soon. Or you can just contact the organisers. Above all, don't shy away from robust criticism. I've been very positive above and I've heard good things from other people. But if something didn't work for you, please say so and explain why.

Back to BAML for the September Dojo


The first Thursday in September saw us back at one of our long-time hosters: the Bank of America (BAML). This time, in their building near St Paul's. We've been there once before, for a Raspberry Pi-themed Dojo. That time we were in a sort of banqueting hall on the ground floor. This time, we started at the other end, on the rooftop for generous amounts of pizza, beer and other hors d'oeuvres, before moving into a conference room for the meat and drink of the evening: coding.


Gautier and others from BAML had prepared a challenge which involved determining the (human) language of a set of texts, given a training corpus. They'd suggested the possibility of using scikit-learn and the Natural Language Tookit, but left it open to teams to find their own way.

One thing about the London Python Dojo is that we emphasise the need to welcome and encourage newcomers, both newcomers to this particular forum and newcomers to the language itself. Early in the evening, Gautier arranged some reshuffling so that more experienced Pythoneers weren't clustered together, leaving neophytyes to flounder alone. So across the table from me was Nathan, giving a Psychologist her first real taste of Python, she having had no more exposure than reading the tutorial for a while.

I was asked to help two developers who were experienced in other areas but new to Python. We stuttered along for a while trying to understand the Natural Language Processing toolkits at which none of us had any knowledge. But we soon decided to switch to more primitive techniques of frequency-matching. Since both of my other team members were new to the game, it was more a question of walking them through the kind of approach, and getting to a simple point of recognising one language from a well-known marker. But they both managed to get that far.


Thanks, as usual, to BAML for its continued support of the London Python Code Dojo. I'm glad to say that a number of organisations have come forward in answer to my call for support to offer their venues for this year's session of Dojos. But we can always use more: if your company is in a position to offer space for about 30 people and, ideally, beer & pizza for the same number, then please let us know: or @ldnpydojo on Twitter.


Helping educators

tl;dr If you’re a teacher looking for help with any aspect of IT, there are people willing to help. For free! Drop by the Twickenham Coding Evening [actually in Richmond] on June 21st. You can just turn up and say “who can help me with this…?” or you can stay for a while and see what else is going on.

It’s no great secret that many teachers are overworked and under-supported. It’s also the case, thankfully, that there are many people who are willing and able to try to remedy some of that (mostly the under-support rather than the over-work). But the under-supported and the willing-to-supporters don’t always meet in the middle.

I’ve been a casual lurker on the Computing At School forums for a few months and people occasionally advertise local meetups (called “Hub Meetings”). But they’re, understandably, timed to facilitate teacher attendance, typically at 4pm or a little after. As helpful as I’d like to be, I work full-time in Central London and, even if I stretch my hours a little, I’d struggle to make a meetup anywhere at 4pm. Coming from the other direction, I help to organise the London Python Dojo and we’d welcome teachers to come along and participate. From time to time, we even make the Dojo especially education-oriented. But for a tired & busy teacher, taking out an entire Thursday evening somewhere in Central London for a beer & pizza coding meetup may not have the same appeal that it does for a buzzing techie who’s just finished work somewhere nearby.

Is there a single answer? No, not really: people are different. One person may like diving in to interact with people they’ve never met; another might shy away unless they’re certain of a friendly reception. Another factor is that the majority of techie meetups are male-dominated. They may be as friendly and welcoming as you like, but a lone woman might well feel out of place and/or in the spotlight. And some proportion of teachers are women. I’ve no idea what the ratio is, but it’s got to be different from the 1 in 99 common in tech circles.

Clearly what’s needed is a variety of support channels to meet those various needs and preferences. There’s a bit of soul-searching at the moment on the Cas forums over whether they’re useful or not, but what it comes down to is that some people find them useful and welcoming, while others don’t. That’s going to be true of pretty much any forum (in the broadest sense of that word).

So don’t agonise over whether some initiative is going to prove fruitful or not: just go ahead and organise it, advertise it, make it as friendly and useful as you can. And go from there.

More or less since its inception I’ve been helping at the Twickenham Coding Evening, organised by the dynamic Cat Lamin, originally a teacher, now something else. It’s a completely informal thing, more or less once a month, until now in a room over a pub. It’s just moving venue and the next session is June 21st. It’s basically a bunch of techies offering whatever help they can to any teachers who might drop by. Some of the technical people are also teachers or teacher-support; some, like me, are in industry. Sometimes there are demos of things; but, really, it’s just an open house. It takes place from 6.30pm onwards, notionally finishing around 9pm. There’s no particular structure: just turn up and say hello.

So, if you want specific help with a specific thing, come along and ask: “How do I remote control my robot using Python?” or “Can I do random numbers in Scratch?“. If you’re looking for more general approaches / advice, just ask: “I’ve got a bunch of micro:bits; what can I do with them?” or “I’ve been told I’ve got to teach coding to Year 7s next year; what’s available to help me?“. If you’re looking for hardware ideas or experience with particular pieces of kit: “I’ve got a budget of £10 per kid; what can I get to teach physical computing?” or “Is it worth getting a classroom set of Crumble Bots?“. There are usually people from Code Clubs and people with teaching experience as well as people, like myself, who are full-time coders but with a side-interest in helping education.

You don’t have to stay for any particular amount of time. Just say Hello and start asking for advice — or offering it! if you’re an enquiring teacher who needs help with IT, I look forward to meeting you on June 21st.

School Dojos, Raspberry Jams & Worksheets

Useful links:

I’ve been glad to help out recently at a couple of events aimed at getting youngsters coding. The recently-instituted Turing House Dojo took place a couple of weekends ago at the recently-instituted secondary school of the same name in Teddington. And the 2nd Wimbledon Raspberry Jam took place yesterday in Wimbledon Library, courtesy of Albert Hickey and Cat Lamin, supported by Wimbletech.

(The Wimbledon one was a bit odd for me as I was born less than half a mile away and went to school to Wimbledon College. I used to go and work in the reference library after school when I was in the VIth form — and the reference library is now a big open space where we had show-and-tell events running yesterday. The workshop I was giving was in the former children’s library).

Each of the two events had a good showing of youngsters and parents. If I had to guess, the modal age was probably 10 or 11 for both events although with a fair spread younger and older. At the Teddington event, all bar one of the attendees in my group had a parent by their side; at Wimbledon, about half. (I don’t think it was required for Teddington that the parent participate as such, although they do have to be present on site; I think it just worked out that way).

The Teddington Dojo was basically a couple of hours of youngsters in different groups (Basic Python; Intermediate Python; Scratch; Arduino) going through mini-projects or worksheets. The Wimbledon Jam was a more varied affair: 1.30pm to 4pm with half-hour talks in one room, 45-minute workshops in another room, and a large central space with show-and-tell projects including robots, robot football, Flotilla, green-screen and others, all using Raspberry Pi in various ways.

At Wimbledon I helped out in a talk by Nic Hughes (”I’m a parent; get me out of here!”) and then floated for a bit until my own workshop was due. I had decided to use the Breakout clone (renamed “Wall Ball”) which I’ve written about before as the basis for the Intermediate Python activity. I wasn’t banking on too much Intermediate-ness; I was only going to assume that those attending had at least used Python. And even that wasn’t always the case…

I used the same worksheets at the two events, but I learnt a few lessons from the earlier Teddington event. So in the intervening week I tweaked the worksheets for the most urgent elements. As an aide-memoire for myself and in case anyone’s interested in the particular challenges, these are some of the things I picked up and — in some cases — addressed:

  • No matter how much time you allow for set-up, you’ll need more.

    I’d deliberately kept dependencies down: Raspberry Pis come with sufficiently recent versions of Python, PyGame and PyGame Zero that I didn’t need network access to install things. All I needed was: a browser to show the docs (of which, more later), a terminal window, and IDLE or some other editor. Even so, doing all that on 15 Pi’s, even if everything were to work, even with other people helping, can take quite some time. And everything didn’t always work…

  • No-one reads instructions in a workshop

    [This isn’t quite true unfortunately; the secondary rule is that people only read instructions when you’ve made a mistake in them and they don’t work properly].

    The version of the worksheets I used at the Teddington Dojo had an initial step which was intended to show just how much work the PyGame Zero loop is doing on your behalf, to the extent that your “blank file of code” is equivalent to this “15 lines of code” file if you were using native PyGame. Unfortunately, almost everyone didn’t read the explanatory text and simply jumped to typing in the 15 lines of PyGame code.

    For the Wimbledon Jam I just removed the example code to a section at the end which gave some information about PyGame Zero with a link for those who were interested enough.

  • Using the local network for documentation should be a good idea, but can easily be brittle before or during the workshop

    The worksheets are Sphinx-based, available on Read the Docs, and built locally on my laptop, which is connected to the local network. At the Teddington Dojo, the network segment they’d helpfully set up for us was so locked down that trying to access one address from another on the same, restricted, subnet was a no-no. Fortunately, the tech support firm who were also sponsoring the event with kit had a man on site who fixed us up. Even then there were some inexplicable routing glitches. At Wimbledon, using a repurposed TalkTalk router, the Pi’s seemed to be in contention with each other, meaning that none of them brought up the necessary webpage in the vital moments before the workshop. Eventually they started getting over each other and the page popped up successfully.

    To minimise further issues, I had built a singlehtml version of the page (although I would have preferred to use the step-by-step html version). As a fallback, I had the singlehtml version on a memory stick which we copied from for the most stubborn of the Pi’s at Wimbledon.

  • It’s best to walk through the very initial steps with everyone, out loud

    The first steps involve making sure IDLE and a terminal window are up and then creating an empty file in IDLE and using pgzrun to execute it under PyGame Zero. With the network problems, we’d not had time to go round getting IDLE/Terminal up and running before kids started to arrive. With hindsight, we had enough helpers for me to give the instructions out loud and get everyone running with the basics before leaving them to their own devices. At Wimbledon we only had 45 minutes so we didn’t want people to “waste” time bringing up the tools.

  • People will cut-and-paste, no matter what you say

    Although it’s part of the “How to use these worksheets” section (which I didn’t expect anyone to read) I didn’t announce up-front: “Don’t cut-and-paste”. I did remember to say that the purpose of the workshop was not to get them running a game, but for them to understand how the game ran and to make it their own. But several of them had cut-and-pasted wholesale before I realised what was going on.

    I was helping at a workshop in PyCon UK where the organiser had generated PDF with the code as images so you couldn’t cut-and-paste. I did consider this or some similar trick, but I’d worked quite hard to get the highlighting working, of which more below, and I didn’t want to jeopardise that.

  • Call the file the participant’s name

    This was always in the worksheet as I had experience from elsewhere: tell the youngsters to call their game “” or whatever. This is especially because, at the end, a number of them want to take the code home but haven’t brought a memory stick to copy it to. So I ask them to add their parent’s email address to the file and then copy the file with its name to a memory stick from which I can email after.

  • Highlight the code which is changing

    This is where I put the most work in. The worksheets are essentially a series of steps each with a section which shows the code, a section which explains the code, and a section which suggests changes you could make, sometimes with a hint as to how to go about it.

    Behind the scenes, these were using the Sphinx literalinclude directive to drop actual code files into the Sphinx doc which allowed me to test that the code was working and allowed for easy comparison of code versions. However, this means that the same code was appearing at each step, only more of it. Some participants made the mistake of typing (or cut-and-pasting) the entirety of the new code after their existing code. (Which will actually work a lot of the time but is very confusing to debug!).

    So I developed a simple Sphinx extension called literaldiff, cloned from the built-in literalinclude, but which added diff highlighting. (The built-in literalinclude has a diff option, but that generates a unified diff which is not an easy thing for beginners to read!). The literaldiff directive means I can simply give the new code, specify its “parent”, and see the new code formatted as usual via Pygments, but with the changed lines highlighted in yellow.

    The problem is that Pygments (which Sphinx hands off to for formatting) only has one highlighting mode, so I had no easy option for highlighting the few situations in which I was removing code. I resorted to a fairly hacky solution which involved prepending comment text saying “#DELETE –>” and hoping that it was obvious enough what was happening.

In both events, the parents and youngsters taking part were enthusastic and receptive. Some more than others, naturally. The 2-hour format of the Teddington Dojo meant that younger kids were flagging towards the end. The Wimbledon Jam had only 45 minutes plus a little overrun and all but the youngest got through to step 2 (moving the bat). Several finished the worksheet altogether and had moved on to the extension sections at the end, which was the idea.

I still have work to do with the worksheet format, but after two events, I’m fairly happy that it’s mostly workable and I hope to take it to other Jams / Dojos and make it available via readthedocs for other people to use.

Rambling Thoughts on PyCon UK 2016

[UPDATE: People reading this might get the impression that my experience was negative. Really, though, it’s just that, for reasons outside the Conference, I was rushed and not really prepared and so didn’t enjoy things as much as I might have done. In other words, the negative tone is subjective rather than objective!]

If you track back through my write-ups of my previous PyCon UK experiences, you’ll see a bit of a trend: every year I say something like “This year was different”. And so it was this year. But this year it was differently different: it was different for the whole of PyCon UK, not just for me.

PyCon UK was famously the brainchild of John Pinner (RIP) and was organised and run by him and a team of Python enthusiasts from the West Midlands with help from elsewhere. But we had clearly outgrown our Coventry venue: in the last two or three years, the facilities have become increasingly strained.

So this year we were in Cardiff where Daniele Procida and others have successfully organised DjangoCon several times. Specifically we were in the City Hall which gave the conference more capacity and, I’m told, a slightly more responsive building staff over the weekend. I haven’t seen many facts or figures from the organisers, but certainly over 500 people were registered, in contrast to something like 300 for the last couple of years in Coventry. I don’t know if that’s because the size of the venue allowed more tickets to be made available or because Python has had a popularity explosion in the UK. I also don’t know whether it includes the Teachers’ and Children’s tickets, or those for the Open Day. Still: bigger.

I was unable to take any time off work around the conference. We have a highly important deadline fast approaching for a Big Contract and all shore leave was cancelled. I was especially sorry to miss the Education Day for teachers, which I’ve been involved with since its inception 4 or 5 years ago. So when I finally arrived on Saturday morning, I went straight into the Kids’ track which was running a Code Club session on Racing Turtles. I’d heard not long before the Conference that there hadn’t been much take up for the Kids’ Day, so I was very glad to see that the place was packed with children & their parents. Unscientifically, I’d say that most were between 9-12 with a small number above and below those ages. Probably rather more girls than boys.

After the break, there were sessions on Minecraft and micro:bit. I helped with the latter – I’m not a fan of Minecraft! And after lunch was a free-for-all in the Kids’ Track. The idea was to work on anything which had taken your fancy in the morning. I know from previous years that this sometimes works and sometimes doesn’t. (Generally parents of younger kids who are disengaged tend to take them away at this point). But for those old enough, or whose parents are keen enough, it was a great chance to explore possibilities. At different times there were quite a few conference-goers popping and out to offer help, although sometimes it’s not needed as everyone has their head down in a project.

I always enjoy the youngsters at Python. Of course, not every child gets as much out of things as they might do. Some of the worksheets needed a lot of reading and then a lot of typing which was daunting especially to some younger participants. (And laziness is A Thing, of course!). But it’s great when the children get the bit between their teeth and get excited about what they’ve achieved… and that they worked it out themselves, and debugged it themselves. And they’ve got an idea about where to go next.

For various reasons I spent relatively little time at the Conference proper. In particular, I only attended three talks, all of them given by people I knew and containing few surprises. It’s nice to see that several projects which I was slightly connected with early on have grown considerably and definitely merit a newer look: GPIOZero, PyGame Zero and PiNet. Like everyone else, I was impressed by the talk transcribers.The Conference venue was very pleasant and what I saw of Cardiff was welcoming – even though they were milking their connection with Roald Dahl, who’d been born there 100 years before.

People have spoken and tweeted about how welcoming and open PyCon UK was for them, and I’m delighted. For me, the experience was a mixed one, I think for two reasons. One was that I was there for considerably less than 48 hours: I arrived on Saturday morning and left mid-afternoon on Sunday. I had necessarily little time to interact with people and, once I’d helped with the Kids’ Track, I particularly wanted to catch up with Andrew Mulholland of PiNet fame, and to say hello to people I pretty much only see at PyCon UK. Floris wanted to chat about networkzero and, once I’d done all that, it was almost time to go. I had an hour in the glorious Quiet Room (aka Cardiff City Council Chamber) before heading off on a coach to Bristol followed by a 2+hr stand on the train back to London.

The other thing which muted my experience was how much bigger the Conference was this year, how many more people. Obviously, the fact of its being in South Wales will have skewed the catchment area, so to speak. But I was surprised at how few people I knew. Of course, at one level, this is great: the Python community is big and getting bigger; I’m not in an echo chamber where I talk to the same 12 people every year; people from the South & West who couldn’t get to Coventry can get to Cardiff. At the same time, I was irrationally lower in spirits (partly through lack of sleep, no doubt!). Normally I have no difficulty in just stopping by people to say things like “My name’s Tim; what do you use Python for?”. But this year, I just found it harder. So – sorry to people whom I appeared to be ignoring or who found me distracted.

In particular I realised how much I’d missed by not being there the previous two days: it’s a little like starting at a new school when everyone else has already been there a while. There’s nothing I could have done, but I regretted it nonetheless. Hopefully it’ll be better next year.

I look forward to seeing other people’s post-Conference write-ups and photos. I’m especially interested in people who didn’t enjoy things, or at least weren’t bowled over. Not because I’m reaching out for negativity, but because surely some people will have had an indifferent or even a negative experience at some level, and it would be good to understand why.

Well there’s more I could say, but if you’ve even read this far, that’s more than I expected. I hope I’ll see you there next year, and meanwhile enjoy the tweets.

Teacher feedback wanted on NetworkZero

I recently released a Python package called NetworkZero. It makes it easy to add a bit of network sparkle to an existing application or to create a wholly network-based application. There is an emphasis on usability in a classroom or coding dojo where things like network addresses aren’t always easily known or communicated between members of a team.

It’s on PyPI so can be installed by pip: pip install networkzero. The docs are on and the code is available on Github.

What I’d really like now is feedback from teachers or people who run code clubs or dojos, jams etc. If you can actually install and make use of the code, then great; please let me know if it’s helpful. But before that, I’d like to know whether it *can* be installed, or even before that, whether the documentation makes sense and is useful.

Too often I’ve read the docs for some hopeful-looking module or tool only to end up asking: “But what does it *do*? What problem is it solving? And why should I prefer it over the several other existing tools in the same space?”. I hope that I’ve answered these questions, but of course I know the answers beforehand, so I can’t be sure!

If you encounter specific problems either in the docs or in the code itself, feel free to raise a Github issue. (Or, indeed, a PR). Otherwise, please ping me on Twitter and we can continue by email or other means if a longer discussion seems worthwhile.

Thank you for any feedback you can give, and I hope that NetworkZero can become a useful addition to your toolbox

NetworkZero at the London Python Dojo

The London Python Dojo was hosted yesterday by Hired, an unashamedly promotional move by the job search marketplace firm. Their offices are in Southwark, not far from Borough or London Bridge, a welcome change from the Old Street area where we’re often hosted.

After the usual beer & pizza, kindly provided by our hosts, we had a fairly quick round of voting which ended up with most people wanting to try out my Network Zero package, advertised and just pipped to the post at the previous Dojo. I gave a quick demo and explanation, pointed to the github repo and the readthedocs page and let people loose.

Amusingly, our hosts — not being a tech startup which most of our hosts are — didn’t really have an easy way for guests to access WiFi. They did offer us an ethernet cable. So, in a network-centred Dojo, we had a combination of link-local connections, tethered phones, and a wired internet connection shared via a OS/X hotspot. Apart from anything else, it really showed up some of the shortcomings of the NetworkZero approach, especially in the area of the UDP broadcasts supporting the advertise/discover mechanism.

Fortunately, everyone got something working after a bit of experimentation and several people provided PRs, raised issues, or just told me of difficulties they were having. Thanks especially to Sandy for bringing his undoubted networking expertise to bear on the innards of the project.

I had held off uploading anything to PyPI until after this event in case any obvious instability or major flaw were to show up. But this caused some surprise when people couldn’t simply pip install networkzero. (Fortunately it’s very easy to clone the repo and pip install -e .). I’ll be reviewing the issues & PRs and then, hopefully, publishing to PyPI.

I now want to put the code in front of teachers to get their feedback on its usefulness and usability.

Thanks, of course, to our hosts — Hired — and to O’Reilly who continue to support us with a book to give away at the end of the Dojo.

Network Zero

There’s a small trend in the UK-based education-related Python development world: creating easy-to-use packages and using the suffix “zero” to indicate that they involve “zero” boilerplate or “zero” learning curve… or something. Daniel Pope started it with his PyGame Zero package; Ben Nuttall carried on with GPIO Zero; and I’ve followed up with Network Zero. FWIW I’m fairly sure the Raspberry Pi Zero was named independently but it fits nicely into the extended Zero family. Nicholas Tollervey was even excited enough to create a Github organisation to collate ideas around the “Zero” family. His own Mu editor [*] although lacking the naming convention is, in spirit, an Editor Zero.

We’ve never really talked it out, but I think the common theme is to produce packages especially suitable for classroom & club use, where:

  • The *zero package sits on top of an established package (PyGame, GPIO, 0MQ) which more advanced students can drop into once they’ve reached the bounds of the simplified *zero approach.
  • The emphasis is on up-and-running use in a classroom or club rather than clever coding techniques. There’s a slight preference for procedural rather than object-based API (although everything in Python is an object but still…)
  • Helpful messages: where it’s feasible, error messages should be made relevant to the immediate *zero package rather than reflecting an error several levels deep. This goes a little against a common Python philosophy of letting exceptions bubble to the top unaltered but is more suitable for less experienced coders

My own Network Zero is definitely a work in progress, but I’m burning through all my commuting hours (and a few more besides) to get to a stable API with useful examples, helpful docs and tests which pass on all current Python versions across all three major platforms. Tom Viner has been incredibly helpful in setting up tox and CI via Travis & Appveyor.

If you feel like contributing, the activity is happening over on Github and the built documentation is on readthedocs. I welcome comments and suggestions, always bearing in mind the Design Guidelines.

Any teachers I know are welcome to comment of course, but I’ll be reaching out to them specifically a little later when the codebase has stabilised and some examples and cookbook recipes are up and documented.

Feel free to raise issues on Github as appropriate. If you have more general questions, ping me on Twitter.

[*] I think Nicholas should have embraced the Unicode and named it μ with the next version called ν (with absolutely no apologies for the cross-language pun)

Python on the micro:bit — TouchDevelop or the Mu editor?

You may have noticed that the BBC micro:bit has been launched (for the third time, I think). This time, it’s actually being to delivered to schools and teachers have the opportunity to use it with their Year 7s (11-year-olds).

Some of them will be using the Block Editor, a sort of Scratch-alike provided on the official micro:bit TouchDevelop website.

But we hope that many will choose to use MicroPython, the complete re-implementation of Python specially designed to fit onto small boards and embedded systems. A lot of work has gone into making sure it runs well on the micro:bit and has a special “microbit” module from which you can import all the tools you need to access the LEDs, the accelerometer etc. You can read about it on the micro:bit community page on the Python website.

Earlier this week I helped out at a workshop organised at Maidstone Grammar School by CAS South East to introduce some Kent-based teachers to Python on the micro:bit. One issue which arose was whether to use the TouchDevelop Python editor (created by Nicholas Tollervey) or the standalone Mu Editor (created by Nicholas Tollervey). As I spoke to the teachers at that workshop, there was an amount of confusion & misunderstanding so I lay out here what you need to know about each editor.


The most important point is that it doesn’t matter. Both editors have the same purpose: to provide a means to run a Python program on the micro:bit. The same code, the same version of Python, the same result on the micro:bit.

The choice will be down to how the points below interact with your preference, your environment, and the restrictions in place in your school. Also the extent to which you want to achieve commonalities with (a) other TouchDevelop languages; or (b) a local solution (eg because you’ve invested in Classroom for Github).

The TouchDevelop Editor

  • The TouchDevelop editor obviously integrates with the TouchDevelop world, saving scripts which can be shared with other TouchDevelop users. It follows the same pattern as the other TouchDevelop languages and therefore benefits from familiarity with those.
  • The TouchDevelop scripts are inaccessible except via TouchDevelop. (Although you can obviously cut-and-paste out of the editor but still…). You can’t, eg, hold them on Github or on your PiNet setup.
  • TouchDevelop requires you to be online. UPDATE: Peli de Halleux points out that it works offline.
  • TouchDevelop runs in the browser so no new software or installation is needed. (I don’t know whether it will run inside the standard browsers on the Raspberry Pi).
  • The process to get your TouchDevelop script onto the Microbit is very slightly more involved than the equivalent Mu process.

The Mu Editor

  • Mu does not require you to be online
  • Mu works like any local editor (I found myself saying “think of notepad”).
  • Mu saves files locally so does not share by default but can make use of whatever your standard filesharing solution is (Google Drive, Github, school fileserver etc).
  • Mu can copy your code directly to the micro:bit to run immediately.
  • Mu requires you to be able to run arbitrary software (albeit without installing) on the classroom machines.
  • Mu allows you to program directly on the Microbit via the REPL. However…
  • … on Windows, use of the REPL requires installation of a driver which may not be possible (at least without some bureaucracy).