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 readthedocs.org 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.

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!