Archive for Python

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).