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.

General

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

Planet Python: an unintended trip down Memory Lane

So… you may have noticed some rather antique posts popping up on Planet Python this morning. This is the result of two things: our clearing out the cache to try to address an issue [*]; and the way in which the feed parser tries to pick up the dates from the feeds it’s scanning.

For now, treat it as a unique chance to view the Python blogosphere through the spectacles of yesteryear! The older posts should just drop down as others are updated, but if they don’t we’ll do a little surgery to the config. In any case we’ll try to do some code housekeeping against any future outbreaks of nostalgia.

[*] … and which didn’t fix the problem!

Planet Python

One of the many pieces of the python.org “family” is a feed aggregator: Planet Python. It’s been running for years either as planetpython.org or planet.python.org (the latter now redirects to the former). Naturally, over the years, some of the blogs it aggregates have disappeared. But it can also happen that the feed URL changes because of a change of blog engine, a new domain, a switch to https etc.

These days, the Planet configuration is maintained on Github and you can either submit a Pull Request or just email the Planet team. We probably add two or three new blogs every month and tweak a couple more (new URLs etc.)

So… please check the Planet config file or look down the left-hand side of Planet Python and, if your blog is listed but is now dead, please send us a PR or an email. Likewise if the blog is still alive but at a different address, please do the same. After a time, we’ll run a cull of Blogs which consistently return 404 and thin our list down.

Of course, please also ping us if you’d like to add your blog. Easiest way is to open an issue or raise a PR which will use Github’s recently-added issue template mechanism to make sure you’ve got everything lined up.

ESP8266 Dojo at Marks & Spencer Digital

I don’t usually reference chip names in my post titles, but this neat little chip was very much at the heart of yesterday’s London Python Dojo at Marks & Spencer Digital near Paddington.

For those who don’t know, Damien George, creator of MicroPython recently launched a Kickstarter to help development of MicroPython, specifically targetting the ESP8266. He was good enough to bring along a handful of boards with this chipset with a view to our hacking on them with Micropython. He explained to us something of the background of MicroPython (which is now his full-time job, hence the Kickstarter) and of the chip which seems to have a hit a sweetspot of power and price and is hugely popular among hobbyists far removed from its origins in a Chinese technology factory.

To honour Gautier’s turn as cat-herder, we’d been having a bit of Franglais badinage on the organisers’ mailing list. But then Nicholas, who’d arranged for us to use M&S, went one step further and our pre-meetup refreshments took the shape of wine, cheese & baguettes. (And some suitably French musique!).

Inevitably, when it came down to getting up-and-running in our different teams, there was a fair scramble as most people had to come up from scratch to getting a board flashed and then working with some kind of peripheral. Damien had helpfully set things up so a simple “import mswifi” would attach to the necessary WiFi, but after that we were on our own. We had two small teams with only one board but we did have a neopixel strip, so we set to doing something with that.

One stumbling block was that all of Damien’s demonstrations (via Serial-over-USB) had been on a Linux box and we had a mixture of Linux, Mac & Windows. There was an amount of faffing about to recognise and connect to the device on various boxes, but we ended up using a Linux box which led us to the next problem: everything has to happen in the interactive REPL, short of a complete reflash. So Tom was shuttling text to and from an editor and the embedded REPL via picocom. All this is happening quite quickly, and with little or no documentation on the (quite extensive) facilities which MicroPython brings on the device. So you become both pragmatic and inventive in your workarounds.

Finally we got a simple example where a Heroku-based Flask app allowed someone to set up an array of RGB colour values while the ESP8266 device would poll that website periodically, decode the JSON, and change the pixel array accordingly. It was rough and ready, but it worked.

Other teams did similar-ish things: one was trying to use an add-on screen to render the well-known Star Wars ASCII Art telnet feed. Another team had a small fan controlled by the device and managed, like ours, by a text file on a web server which was updated by Carles via an SSH session on his phone!

A number of us had ordered devices (at short notice) for the event, but most hadn’t received them in time not least because the same distributors are currently flooded with orders for the brand new Raspberry Pi 3. Hopefully, when they do arrive we’ll be able to get MicroPython working on them without difficulty.

You can see a few photos via our Twitter feed.

Thanks again to M&S Digital and Nicholas for hosting and for the French food, for O’Reilly for continuing to supply us with books as giveaways, and to Gautier for keeping everything on an even keel. And especial thanks to Carles who stuck with me when I thought I’d lost my Oyster card.

See you next month.