[Microbit-Python] Python Subsets, what the microbit prototype does/doesn't do.

[Michael]

Hi,


tl;dr - background on the prototype and a first cut of what a python subset
must support

I don't know how much everyone knows about the project, or what everyone
understands or doesn't about what is wanted out of this part of the
project, and by who/whom/etc :-)

So, this email aims to cover at least *enough* about the former - and to
ask some questions about the latter - from the perspective of
python-subsets :-)

On that former point, I assume most people know *enough* about the project
to be on the list in the first place but don't have much detail. If that
assumption is wrong, sorry! :-)

Anyway, to frame the python context below, and glossing over lots, the
short version is:

 - Idea was come up with and tested at events

 - I was brought on board to build a production-*capable* version from
scratch with the intent of testing in schools, and working with partners to
take to scale. The key requirement of the former was a robust solid working
system. The key requirement of the latter was the ability to swap out
*every* part of the implementation with something better/more appropriate
for scale. (Conflicting forces, but useful ) (One of the key aspects there
was the possibility of even having multiple different hardware
implementations...)

- As a result that version is now referred to as "the prototype", but is
more robust/useful than your usual prototype, and in the case of any python
interface worth looking at to see what could be done better, or kept or
rejected.

- (Once I'd built this, and it'd been tested it in schools, etc, I was
pulled back into R&D and I'm currently working on something completely
different... So I'm only writing this in a quiet moment...)

The prototype site which I developed (along with the prototype
hardware/etc) can be found here:

* http://bug.iotoy.org/bug/

While it's a prototype, it's a fully functional thing - there's a lot of
love been poured into its creation :-)

That said, the prototype MUST be taken with a pinch of salt - since the
final hardware *is* more capable, and the website/etc for the final
hardware is radically different, despite sharing the same vision. (After
all, that was one of the aims :-)

I'm mainly mentioning it though because it's a complete working version of
the sort of thing microbit is :-)

Also, there's some practical aspects - many of the programs on there were
created by children, and gives an indication of the code complexity that
might be used. (the server doesn't hold *any* personal data for children)
This means all the programs on there (and their development history - which
is retained) are useful data.

Anyway, the most complex example I've seen on there is this calculator:

http://bug.iotoy.org/bug/program/2454/Calculator

Python code gets generated for that (visible in the code tab) -  gets
compiled to C++ before being compiled using a normal embedded toolchain.

That's practical due to the constrained version of python used - which in
the case of the prototype is limited to the python that the blocks can
create. To allow python as input would require a sufficiently constrained
*version* of python, which is tractable for compilation, but was still
clearly python.

I think that for me is really the starting point. What, if it was missing
from python, would mean it wasn't really python any more? What are the
lines in the sand? (I've clearly got ideas, but would be interested to hear
opinions)

For me the starting points are (except for "import this") : (in no
particular order, but matches my aspirations for my pet project 'pyxie' :-)

 * Duck typing / lack of type declarations (but strong types)
 + Whitespace for indentation
 + Standard control structures (No else clauses on while/for :) )
 - Lists and dictionaries
 * Easy import/use of external functionality
 - User functions (and associated scoping rules)
 - Classes
 - Namespaces
 - Exceptions
 - PEP 255 style generators (ie original and simplest)

Things that the prototype doesn't support - due to lack of time - are
preceded by a -, rather than a +. * means "sorta" supports - due to
sidestepping by targetting C++11'. (I only really include generators
because I've built C++ versions of those in the past :-)

This obviously leaves lots of things that people use which I would say
*could* be left out like...

 - decorators
 - nested/dynamic functions, closures, nested/dynamic classes,
 - object/class monkey patching
 - Metaclasses
 - dict based onjects
 - __getattr__ / __setattr__ (feels very wrong to say that :-) )

... not because they're not useful, but because they might not be useful in
this context.

Anyway, that's my tuppenceworth :-)

Regarding compiler vs interpreter on the device, I've not seen any specs
for the final device - nor how much of those resources are available at run
time (I'm not involved in the day to day of the project at the moment), but
my understanding is that we're still well below the threshold required for
something like pymite or micropython. (If I'm wrong, awesome :-)

If the intent was to go down an interpreter route instead, then maybe
compiling to a forth-like VM might be an idea? (I suspect this isn't
realistic, but worth raising as one way of allowing things like nested
functions/etc if people felt that python wouldn't be python without them :)

</tuppence>

Opinions?


Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20150608/f031dc97/attachment-0001.html>