After having taken a stab at fixing a couple of issues within the main
implementation of Python, I decided whilst waiting for some of those pull
requests to be merged I might try to contribute to some other open source
projects in the Python ecosystem that are endorsed by the PSF.
Lewis suggested taking a look at Beeware, which recently received a grant from the PSF Education group to improve support for Python on Android, as part of their mission to enable cross-platform Python-based native apps.
There’s a lot of pieces to Beeware that are in early stages of development and support, and should be ripe for further contribution. However, the first stages revolved primarily around familiarising myself with the ecosystem to understand which pieces would be most suitable.
Beeware has several constituent projects, some of the relevant ones are:
toga: a cross-platform native widget toolkit, that provides a high-level API wrapping the concept of an
App, allowing users to build GUI applications which resolve to using native widgets on the target platform
colosseum: an implementation of the CSS specification for resolving positions and locations of elements on a canvas, used by
togafor styling applications
voc: a transpiler which converts Python bytecode allowing Python to be compiled into Java bytecode and run on the JVM, enabling Android native apps
The one which is most obviously approachable starting from a background of just
Python (as opposed to native widget libraries like Cocoa, GTK+, or Java and
colosseum, which is a complex problem but well-defined, and
comes with a suite of (currently failing) tests which verify it meets the CSS
Attempting to Contribute
As suggested on the
I selected a test (at random) from the list of “known failures” and removed it.
Re-running the tests, I took a look at what exactly fails as part of the test.
What I found was not particularly amenable to a contribution: it appears that an
implementation of an object expects a certain class which depending on the type
of the object would contain a certain field. But for the main
layout API, this
object was always being passed in as
None, seemingly because that whole class
of objects hadn’t been implemented:
def layout(display, node, standard=HTML5): containing_block = Viewport(display, node) font = None # FIXME - default font node.layout.reset() # 10.1 1 layout_box(display, node, containing_block, containing_block, font)
FIXME. It appears that a lot of the current issue with
simply missing functionality: code which has been written in a certain way
(knowing it will be needed to meet the CSS spec) but is being fed by defaults
This represents both a difficulty and an opportunity: once the requirements are understood, and the problem fleshed out (probably via interacting with the core devs) there is certainly clear work to be done which just requires skills already available to our team, designing and coding Python.
After talking to some of the core devs on the
gitter, I’m somewhat hopeful that they’ll
be able to direct us at some work to be done, which might represent good group
projects for further contribution in the New Year.