I took some time this morning to reflect on learning CircuitPython.
An interesting challenge is that Naming Conventions have not kept up with code and documentation development. That is very reasonable give the high pace of development in general. The result is the same things being called different names in different place of by different people.
A CircuitPython manual of style might be helpful. These are probably 4.0 milestone type enhancements. A couple examples include:
- Port and Board are used interchangeably. This is reasonable given how they evolved from the single micropython concept of machine. It might more sense to refer to a port as an abstract 'class' which contains the information to build boards using similar chip-sets. Whereas, a board is a instantiation of a port for a particular devboard based on the the specifics of that board.
ie . CircuitPython has been ported to the atsamd chipset. CircuitPython has been implemented on the feather m0 Express.
- CircuitPython vs circuit python. Again this is a minor thing but clarity can be increased if everyone refers to the project and software the same way with the same spelling. It makes sense that the focus has been on differentiating CircuitPython from micropython. Now, CircuitPython seems mature enough to emphasis its own unique identity.
Library naming was the first place where I started getting frustrated with Circuit Python. It took me longer than I care to admit to internalize that http://circuitpython.readthedocs.io/en/latest/docs/drivers.html , https://github.com/adafruit/Adafruit_CircuitPython_Bundle , and '/lib were all referring to the same thing.'
The confusion is amplified by the fact that different boards have different built-in functions. Memory limitations prevent all modules/packages from being installed on all boards. For what it is worth EVERY project struggles with these types of classifications and what to call them. Terms like core, main, supported, unsupported, community, universe, and multiverse come to mind.
None of these issues are show stoppers but they can add clarity to the project while being easy for developers that work among the weeds to overlook.
I took some time this morning to reflect on learning CircuitPython.
An interesting challenge is that Naming Conventions have not kept up with code and documentation development. That is very reasonable give the high pace of development in general. The result is the same things being called different names in different place of by different people.
A CircuitPython manual of style might be helpful. These are probably 4.0 milestone type enhancements. A couple examples include:
ie . CircuitPython has been ported to the atsamd chipset. CircuitPython has been implemented on the feather m0 Express.
Library naming was the first place where I started getting frustrated with Circuit Python. It took me longer than I care to admit to internalize that http://circuitpython.readthedocs.io/en/latest/docs/drivers.html , https://github.com/adafruit/Adafruit_CircuitPython_Bundle , and '/lib were all referring to the same thing.'
The confusion is amplified by the fact that different boards have different built-in functions. Memory limitations prevent all modules/packages from being installed on all boards. For what it is worth EVERY project struggles with these types of classifications and what to call them. Terms like core, main, supported, unsupported, community, universe, and multiverse come to mind.
None of these issues are show stoppers but they can add clarity to the project while being easy for developers that work among the weeds to overlook.