[Microbit-Python] Accessor API design on the micro:bit

Mon Nov 2 15:29:37 EST 2015

Hi Mark,

Excellent points well made. Thank you.

:-)

N.

On 02/11/15 18:32, Mark Shannon wrote:
> 
> 
> On 01/11/15 14:27, Nicholas H.Tollervey wrote:
>> This also makes me wonder about descriptor v accessor in other parts of
>> the API. For example, could we do this?
>>
>>>>> microbit.pin0  # digital read
>> 1
> 
> We could, but we shouldn't.
> microbit.pin0 should be a pin, as it is as at the moment.
>>>> microbit.pin0
> <MicroBitPin ...>
> 
>>>>> microbit.pin0  # analog read
>> 234
>>>>> microbit.pin0 = 0  # digital set
>>>>> microbit.pin0 = 234  # analog set (0...255)
> 
> Again no. Normal assignment rules for an attribute should apply.
>>>> microbit.pin0 = "Hello"
>>>> microbit.pin0
> "Hello"
> 
> Plus, we would have to change microbit from a module to an instance of a
> custom class, in order to support descriptors.
> 
> If we really want to use properties for pins then it should be:
> microbit.pin0.digital(_value)
> and
> microbit.pin0.analog(_value)
> 
> But I prefer the read()/write() methods.
> 
> For the accelerometer, there is no digital/analog state change, and you
> cannot write to it. So accelerometer.x seems consistent with "x"
> appearing to be a simple attribute of the accelerometer object.
> 
> IMO, descriptors should generally appear to have the same interface as
> simple object attributes, even if they are "special" under the covers.
> 
>>
>> Not sure whether digital should be 1/0 or True/False. What's the most
>> widespread convention here? I'm thinking of True/False because that
>> makes it obvious that the pin is digital rather than it's simply a very
>> low reading on an analog in.
> I think digit(al) means digit in base-2. So I prefer 0/1.
> Also pins are high/low. 1 for high, 0 for low seems more natural than
> true for high and false for low.
> 
> Cheers,
> Mark.
> 
>>
>> Thoughts..? Does this make sense..?
>>
>> N.
>>
>>
>> On 01/11/15 14:16, Nicholas H.Tollervey wrote:
>>> OK... what an interesting discussion. :-)
>>>
>>> Then I remembered I had a "captive" 11yo in my home! So I asked him
>>> which one he preferred (and videoed the discussion). Here's the exchange
>>> with my son, over Sunday morning breakfast, in all its glory:
>>>
>>> https://www.youtube.com/watch?v=9w4I_xEwlcA
>>>
>>> Put simply he prefers accelerometer.x over .get_x() and .x() because
>>> it's less typing.
>>>
>>> Emboldened by this feedback I've visited some of his buddies this
>>> morning (I totally realise this is not at all scientific) to get their
>>> opinion.
>>>
>>> I'm quite surprised by the results - they agree with Sam: ".x" is the
>>> unanimous verdict for the best way to express this for all three 11yo
>>> I've surveyed. I was expecting ".get_x()" to win because it was obvious
>>> what it was doing.
>>>
>>> But, for example, Max explained that he didn't like all the "weird
>>> symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
>>> do I need to 'get' it"..? (Max didn't want to be videoed.)
>>>
>>> Lewis, (whose video is here:
>>> https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
>>> of ".x" and felt that all the others just looked complicated.
>>>
>>> So, the evidence I've collected so far appears to support Larry and that
>>> we should trust the heuristic of "simplicity wins".
>>>
>>> Once again, I totally realise this is not scientific in any way. But I
>>> thought I'd ask those 11yo I had within "range" this morning because
>>> they're our target audience.
>>>
>>> I've been booked to do some gardening this afternoon... but will return
>>> this evening.
>>>
>>> I look forward to reading all your thoughts. :-)
>>>
>>> N.
>>>
>>> On 31/10/15 20:08, Carol Willing wrote:
>>>> While I am joining this discussion after a couple of months of history,
>>>> I am going to step back for a moment and ask a simple question:
>>>>
>>>> Does this have to be a decision between x, x(), get_x()?
>>>>
>>>> For the accelerometer (not necessarily all other functionality, but
>>>> since the accelerometer is built into the chip and accessible without
>>>> soldering anything, it will be used by many), could we support all
>>>> three?
>>>>
>>>> If I was an 11 year old with access to Google, I could find resources
>>>> appropriate for an 11 year old that use all three of these approaches:
>>>> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
>>>> for Kids book, and others.
>>>>
>>>> If I didn't have access to Google, I, as a student, would use `help` or
>>>> example programs to model what I would choose. It's critical for the
>>>> educational setting for the approach to be consistent within an example
>>>> program. While in a perfect world that might imply consistent across
>>>> all
>>>> example programs.
>>>>
>>>> Yet, we know that there are several approaches to programming that lend
>>>> the same result but with differing implementations.
>>>>
>>>> It seems to me if there is space to support all three for the
>>>> accelerometer that would make reasonable sense. We can tailor the help
>>>> message to guide to the desired approach; yet, all three will work for
>>>> the student whether they are using a recommended approach or something
>>>> that they googled.
>>>>
>>>> Based on my experience teaching a wide spectrum of children, I do think
>>>> with gentle instruction all levels will be able to use the
>>>> accelerometer.
>>>>
>>>> Warmly,
>>>> Carol
>>>>
>>>>
>>>> -- 
>>>> *Carol Willing*
>>>> Developer | Willing Consulting
>>>> https://willingconsulting.com
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151102/074f0909/attachment-0001.sig>