[Microbit-Python] The BBC reveal the device to the media

Finney, Joe j.finney at lancaster.ac.uk
Sun Jul 12 19:46:16 CEST 2015


Nicholas,

Really just to reiterate what's already been said - PLEASE don't misinterpret my email as in any way implying that we shouldn't get micropython on the micro:bit released to the wild! To my mind, we MUST - it's a great addition to micro:bit, and quite different from all the other language offerings.

I agree completely with what you were saying in your soapbox email (which was truly excellent by the way!). I run the Computing at School (CAS) regional centre for the North West, so believe me, I completely understand where you're coming from on a teachers/curriculum perspective! As you quite rightly stated, diversity is a truly great thing and this should not be a discussion about *if* we do this, but a discussion of the *best* way to achieve it, and integrate it into the package. Let's provide a broad range of offerings, then the different teachers of different kids in different classes and different years will all have the chance to pick what suits them best - be it Python, Blockly, TD, Javascript or whatever. It's all good. :-)

I'll be working on the BLE and USB interfaces for the micro:bit runtime (the DAL) over the next week or two. It would be awesome if we can get the micropython implementation co-habiting with the runtime library if possible. This would be good to reduce duplication of effort and ensures that python users have access to the same, consistent set of core functionality as the other languages - and thereby also gaining you BLE. The runtime library is currently about 650 bytes static footprint, plus about another 300 on the heap. With the reduced SoftDevice footprint we've been working on, this might be just about doable, but we could also look at a custom drop for micropython that leaves out some features you don't need (e.g. the scheduler?). 

This is just one route to explore though... don't let me stop you exploring others. :-)

You guys have access to the MicroBitDAL source code right? It will be open sourced on project launch, but we're under contract not to do so until then. I expect there will be a way to provide access to the necessary Python folks though, depending on how many people you want to include in the development of this bit. This is something you'd need to discuss with BBC folks obviously. Lancaster would be happy to give you any support you need (within our ability of course - we're really pushed for time too!)

p.s. I'm also 41... (well in a few weeks anyway!)... A legendary vintage, clearly. :-D

Joe



-----Original Message-----
From: Microbit [mailto:microbit-bounces+j.finney=lancaster.ac.uk at python.org] On Behalf Of Nicholas H.Tollervey
Sent: 12 July 2015 18:00
To: microbit at python.org
Subject: Re: [Microbit-Python] The BBC reveal the device to the media

Michael,

On 12/07/15 12:57, Michael wrote:
> Quick comments which I hope help - this isn't an either this OR that 
> situation.
> 

Quite... see my reply just now to Howard. I'm relieved it isn't an either this or that, but it's nice to have it clearly stated (rather than a tacet assumption). To be clear, I got the feeling you were all terribly impressed with Damien's work but that you were still evaluating things - nothing had been explicitly stated about support for MicroPython moving forward.

> It's an unexpected awesome curveball.
> 

Tell me about it... :-D

> I don't think there's a single part of what you've written,  that I 
> disagree with. As a programmer, from a free software perspective, from 
> the perspective of tools, from a 'what happens if you lose access to 
> the compiler' (host down, end of life x years down line etc), and so 
> on, heck even from the perspective of a cub/scout leader running a 
> session with 24 kids in a Hall without Internet connectivity,  and or 
> a teacher wanting to keep lesson on track.
> 

:-)

> All of those concerns fed into the system for the schools trial,  and 
> into the recommendation for open source, which fell on a fertile 
> audience (their default assumption) so to speak.  We'd chatted about 
> creating .debs of the system so that schools could run their local 
> servers easily (which is why I'd looked into PPA's), the possibility 
> of a local offline editor with the compilation tool chain, etc. (That 
> used IOToy's PySide based editor).  Indeed,  once the stack is 
> released as open source,  which should include the prototype version,  
> I'll do just that. When it comes to logins, I was rather undiplomatic 
> and detailed and clear about issues, and consequences, etc. That fed 
> into the spec, etc :-)
> 
> That all hopefully explains just how wonderfully surprised we were by 
> micropython. It wipes out whole classes of issues in one swoop, as you 
> say,  providing real fun opportunities,  and capabilities, in a much 
> better way.
> 

Good to hear. Is this all going into your PyCon UK talk..? Pretty much everyone involved from the Python community side of things will be there (as well as teachers).

> Ie, in short I get it,  and I'm also *far* from the only person 
> agreeing with you.
> 
> But,  I'm a 41 year old bloke - not 11, and this goes right to the 
> heart

1973 was obviously a vintage year (me too)

<snip a bunch of stuff that we can discuss over a pint sometime/> ;-)

> Put bluntly,  I think we all know on this list that any solution that 
> doesn't have micropython as part of it would suck, and we're just 
> looking to see where the gaps lie, where they're easy to fix,  
> possible to fix or hard. And that there's a niggle of a worry that if 
> one of the gaps is viewed by kids is important that python *could* be 
> viewed in a way none of us want.
> 

OK... we're all on the same page here.

> Finally,  3 questions,  with the answers I'd suspect in brackets:
> 
> * Does that make sense? (I hope yes)

Yes.

> * Are we overly worried? (Possibly)

Possibly, but it's always good to make sure.

> * Would the python community want to take that risk?  (Almost 
> certainly, it's less of a risk than Python 3)
> 

You mean by not (currently) having BLE..? Personally, I wonder how hard the mythical 32k version of the device would be (at some later date).
Given the Python community's passion about education, not having Python on the micro:bit would be a heinous oversight on our part. That's why I made the proposal on the PSF's behalf. ;-)

I also agree with you about the bounty option. However, for this to happen the Python community would need to be unencumbered to work in the way they're used to. MicroPython is already MIT licensed but we'd need test devices and freedom to discuss, explore and experiment. Schematics, other core data and (I'm guessing) the DAL code should all be available otherwise we're stymied.

Also, this list should be opened up to be public.

> On that basis,  there are IMO two main things to figure out:
> 
> * How to make the micropython dev  environment the best it can be in 
> the time we have.
> 

Agreed. several of us already have various ideas about that already.
Tomorrow or Tuesday I'll start a new thread about it on this list.

> * How to make the UX experience,  including code sharing the best it 
> can be. Perhaps based around using the blocks editor as a template, 
> since that had to store and share text already. However, this is also 
> very similar to the problem that Code Kingdoms are facing for their 
> work, so there's also alternatives there.
> 

Quite... these are interesting problems.

> As I say does that make any sense?
>

Absolutely. As always, many thanks for your always considered and thoughtful contributions!

:-)

Best wishes,

Nicholas.




More information about the Microbit mailing list