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

[Michael]

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> 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
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20150715/b8a494de/attachment-0001.html>