[Microbit-Python] Flat API

Tue Sep 22 07:37:55 CEST 2015

Hi all (& new contributors)

I'd say that both are good, with a proviso....

Please can we settle on a defined core API very soon, as I and my
colleagues are already writing resources based on MicroPython on the
micro:bit, and it's going to be really painful if things keep changing!

Also, we shouldn't force people down an "import microbit" or "from microbit
import *" route, we should let people choose. Everyone on my team prefer
"from microbit import *" as why would you need a microbit namespace on a
microbit, you're sitting in front of the microbit so you know it's one of
those already!

I agree with Michael - both. But please can someone (Nicholas?) define the
core API (basically what we had a week ago that already works!) so we can
develop resources against it, and the other innovation around the outside
can be added as needed.

By define, I mean "write it up in a document, on a github wiki, or
whatever, and version it" and also say "this part is the core part and is
pretty much fixed and this other stuff here is under discussion and might
change".

There's not as much time as you think available to us to get this thing
finished!

Many thanks

David

___________________________________________________________
David Whale, B.Sc (Hons), MIET
*Software Engineer and IET Schools Liaison Officer, Essex*

email:  dwhale at theiet.org
twitter: @whaleygeek
blog:  blog.whaleygeek.co.uk

Co-author of the new book "Adventures in Minecraft" <http://amzn.to/ZGfxZG>
- lets get kids coding!

On 22 September 2015 at 01:19, Michael <sparks.m at gmail.com> wrote:

> 2 immediate thoughts:
>
>  - Firstly I like flat APIs for things, and especially for kids. It's
> simpler to
>    understand - that why the DAL I designed for the prototype was
>    simple and deliberately eschewed various OO features.
>
> - Secondly, the advantage of the DAL though is that it is (or should
>   be) the same across the various platforms/languages. The best
>   analogy I have here is the sockets API. This is the same in C, ruby,
>   python, etc, but often you'll also find a local best practice version,
>   which is often friendlier. That said practicalities here probably decide
>   whether this is good or bad for the production device's DAL.
>
> Let's assume that this doesn't have to be either/or.
>
> In particular this also means that a child who learns at school they can
> make something happen like this:
>
> microbit.pins.pin0.set_digital_value(1)
>
>
> In one of the other languages can bring that knowledge with them,
> when they come to python.  However, it also means they'd be *delighted*
> to discover that in python they can do this instead:
>
> dpin0 = True
>
>
> ie support them in the transition.
>
> As a result, if it's not a choice of either/or, but could do both, I would
> suggest that this would be a good thing. I don't like the word pythonic
> personally, because it's often (ab)used to mean "I do/don't like that".
> In this case though, I think this makes the attributes equivalent to
> properties, and that I quite like and think is a more python-y way of
> doing things that having setter/getter functions.
>
> I like this, though perhaps call the module/package "mb" instead, so
> you could do this:
>
> mb.dpin0 = True
>
>
> ... so that it's short and sweet to type, but retains the benefit of
> namespacing.
>
> </tuppenceworth>
>
> Personally, I have a suspicion that once things become open source, that
> someone may well do a version 2/3 bit, and so keeping a short/friendly
> namespace for this is probably a good idea. (This is complete and utter
> speculation incidentally, but I think reasonable speculation)
>
> Regards,
>
>
> Michael. (who needs to set up a build chain and understand how
> practical/impractical this is)
>
>
> On 22 September 2015 at 00:52, Alan <alainjackson at hotmail.com> wrote:
>
>>
>> Hi All!
>>
>> I had a great time with all of you at pycon UK and playing with the
>> microbit, thanks!
>>
>> On the way home I was thinking a lot about the API and the REPL and 11
>> year old kids. I had a bit of a thought that I wanted to try out - don't
>> shout and scream and hiss. I don't know how much you'll like it.
>>
>> Looking at the microbit module there's very few name clashes within it so
>> I wondered what it would be like if there was a version of it that was
>> almost completely flattened. Especially for using with the REPL.
>>
>> Here's my thinking - the hardware isn't going to change (is it?). It's
>> got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons etc.
>> So when you're in the REPL, wanting to see immediate results on the
>> hardware itself, and you're in such an small, embedded environment, do you
>> want to type:
>>
>>   microbit.pins.pin0.set_digital_value(1)
>>
>> or would you rather type
>>
>>   dpin0 = True  ?
>>
>>
>> Anyway, as a thought experiment, here's an idea of a flattened API. The
>> attributes with an "=" sign means you can assign to them.
>>
>>
>> ====8<====
>>
>>
>>
>> Attributes:
>>
>> dpin0 =
>> dpin1 =
>> .
>> .
>> dpin19 =
>> dpin20 =
>>
>>
>> apin0 =
>> apin1 =
>> .
>> .
>> apin19 =
>> apin20 =
>>
>> pins.analog_period =
>>
>> pixel[0,0] =
>> brightness =
>> display_mode =
>> image =
>>
>> button_a
>> button_b
>>
>> force_x    #accellerometer.get_x()
>> force_y
>> force_z
>>
>> heading
>>
>> compass_x
>> compass_y
>> compass_z
>>
>> compass.is_calibrated
>> compass.is_calibrating
>>
>> system_time
>>
>>
>> Methods:
>>
>> shift_left()
>> shift_right()
>> shift_up()
>> shift_down()
>>
>> write(...)      #display.print(...)
>> scroll(...)
>> animate(...)
>> clear()
>>
>> compass.calibrate()
>> compass.clear_calibration()
>>
>> i2c.read()
>> i2c.write(...)
>>
>> sleep(...)
>> random()
>>
>> reset()
>> panic()
>>
>>
>>
>> ====8<====
>>
>> My little program that scrolls through a message using the two buttons
>> then becomes:
>>
>>
>>
>> from flat_microbit import *
>>
>> message = "1234567890"
>> index = 0
>>
>> while True:
>>     if button_a:
>>         index = (index - 1) % 10
>>     elif button_b:
>>         index = (index + 1) % 10
>>
>>     write(message[index])
>>     sleep(50)
>>
>>
>>
>>
>> Cheers,
>>
>> Alan
>>
>>
>> _______________________________________________
>> Microbit mailing list
>> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20150922/d860caa5/attachment.html>