[Microbit-Python] Flat API

[Michael]

Hi,


I'll refrain from commenting until I see the proposed python API.

I do know that while the trial system supported people forking code/making
changes, and writing their own, the "fork my version" of this code was a
minority use - so the vast majority of code was created from scratch.
Whether that's _representative_ , I don't know, but it's a data point.

Again, the question I'd have is are we aiming to support all children, or
just some.

These are just questions though, and I won't make any more comments until I
see the proposed API. (Also, I don't claim to be right, and it won't be my
decision anyway :) )

Regards,


Michael.

On 22 September 2015 at 15:19, Damien George <damien.p.george at gmail.com>
wrote:

> I think what we came up with yesterday (a few levels of nesting,
> descriptive but not overly verbose methods for everything) is a good
> compromise and we should stick with it.
>
> I think micro:bit code is going to be read *a lot* more than it is
> written (even more so than normal "adult" code).  As such, it's better
> to have clear and obvious naming.
>
> I think kids will spend more time taking existing code and modifying
> it, rather than writing from scratch.  So if they see something like
> "microbit.pins.p0.write_digital(1)" then it's pretty obvious what they
> should change to make it pin 1, or make it a 0 output (but could be
> more obvious if it was pins.pin0).
>
> The most important thing (as David said) is that we decide very soon
> on something, something that's practical and works, so that tutorials
> and demos can be written.
>
> See https://www.microbit.co.uk/td/contents for the Touch Develop API.
> Some things to note (some of these changed since I last looked):
> - they have namespaces and some notion of object orientation
> - they use analog_read_pin, digital_write_pin, etc.
> - compass_heading is in the same namespace as acceleration (both are
> accessors)
>
>
>
> On Tue, Sep 22, 2015 at 2:59 PM, Nicholas H.Tollervey <ntoll at ntoll.org>
> wrote:
> > Hi,
> >
> > WRT API discussions. I have photos of the whiteboard and what we
> > verbally agreed.
> >
> > I'll write up and post later today.
> >
> > N.
> >
> > On 22/09/15 00:52, Alan 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
> >
> _______________________________________________
> 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/affa1af3/attachment-0001.html>