[Microbit-Python] MicroPython on micro:bit TODO list

[Nicholas H.Tollervey]

Hi,

Everyone on this list has signed the BBC's NDA. Off the top of my head,
there are around 15 of us on the list. However, I'd like to make this
list public sometime soon once I've taken appropriate steps to ensure
our "private" history is appropriately audited and those involved are
happy for it to be public (or not).

Howard tells me that things will be open-sourced. I'd like this to
happen ASAP. It's a major hurdle in getting the Python community on
board. I mentioned this to him when we met on Monday.

Howard is on this list and may want to clarify things. A *REALLY* big
win given the conversation so far would be if the DAL was freely
available under an appropriately liberal license.

Howard..?

N.

On 15/07/15 00:26, Finney, Joe wrote:
> Folks,
> 
>  
> 
> Happy to help contribute where I can.  J
> 
>  
> 
> Agree that providing some consistency of experience across languages
> would be good. i.e. the Pythonic interface should feel as familiar as
> possible to the kids’ experiences from other languages. This can only
> help. I can’t see any issues in taking pragmatic decisions where
> appropriate though. It’s the principles that matter. I think Michael’s
> comments re: the DAL in the research prototype still ring true – a bit
> of consistency benefits all.
> 
>  
> 
> I’d happily share a snapshot with you guys, but do need the nod from the
> BBC here, else I risk being in breach of contract…
> 
>  
> 
> How many folks have we got on this list?
> 
>  
> 
> Joe
> 
>  
> 
>  
> 
> *From:*Michael [mailto:sparks.m at gmail.com]
> *Sent:* 15 July 2015 00:01
> *To:* For Pythonic MicroBit related disucssions; Finney, Joe
> *Subject:* Re: [Microbit-Python] MicroPython on micro:bit TODO list
> 
>  
> 
> Regarding 2), if we want a private wiki, or private github repo to
> discuss this, happy to set one up.
> 
>  
> 
>  
> 
> The key thing I found with the DAL in the prototype was that by
> deliberately having one API, it was simpler to track changes. In the
> case of students, if the API matches relatively closely the C++,
> Javascript, Blocks and Touch Develop API, then it allows students to
> bring their understanding with them.
> 
>  
> 
> I'd argue that this "bringing their knowledge with them" as a principle
> outweighs anything "pythonic". (I've often seen the term pythonic abused
> to mean "I don't like that" or "I like that")  I'm not saying "Pythonic"
> is bad, but rather I'm a big fan of the "practicality over purity" idea :)
> 
>  
> 
> Other than that though agree with your principles. 
> 
>  
> 
> For this to happen though, those on this list need access to the DAL as
> it stands today. I know this isn't for you to resolve. I don't know if
> this has happened yet - it doesn't look like it. Without this, we can't
> do anything.
> 
>  
> 
> I do know that if I go to https://github.com/bbc/microbit-extras with
> the github id I use at home (sparkslabs) that I get a 404 not found -
> which is what github shows you when you try to access a private repo
> that you don't have access to.
> 
> 
> cc'ing Joe, since if we haven't he could provide us with a snapshot to
> work from. As I say, without this, we're shooting blind.
> 
>  
> 
> Beyond that practicality point the one thing I would say is that when
> I've used APIs which are python versions of C++ APIs, the closer they
> are, the better. (Not because they're pythonic, but because you're
> dealing with something that doesn't create an extra layer of hidden bugs
> :-) )
> 
>  
> 
> Regards,
> 
>  
> 
>  
> 
> Michael
> 
>  
> 
> On 14 July 2015 at 22:49, Damien George <damien.p.george at gmail.com
> <mailto:damien.p.george at gmail.com>> wrote:
> 
> Hi all,
> 
> Here is a list of tasks for getting MicroPython running on the
> micro:bit to the degree that it can be used by the students.
> 
> 1. The front end.  At a minimum this will be a simple Python editor
> embedded within the web browser.  Nicholas has already started a
> discussion on this.
> 
> 2. Defining a Python API to use the features of the microbit.  Likely
> this is a module (eg "import microbit") that has
> classes/objects/functions that expose various features of the device.
> The design should be Pythonic, simple for studets, and match closely
> the C++ DAL and the TouchDevelop interface.
> 
> 3. Implement remaining features on the device (eg I2C bus support,
> GPIO) and expose them using the API designed in point 2 above.
> 
> 4. Try to get BLE working with MicroPython!  This will be experimental
> work, and can be parallel to the above.
> 
> I think point 2 (defining the API) is something that would benefit
> from input from many people, so please chime in if you have anything
> to say about this.  Points 3 and 4 are "just" coding.
> 
> Cheers,
> Damien.
> _______________________________________________
> Microbit mailing list
> Microbit at python.org <mailto:Microbit at python.org>
> https://mail.python.org/mailman/listinfo/microbit
> 
>  
> 
> 
> 
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://mail.python.org/mailman/private/microbit/attachments/20150715/5ba82515/attachment-0001.sig>