While Sketching wants to be agnostic, it needs to provide
conceptual integrity and, thus, requires an internal unifying paradigm. That in mind, we recognize that it may be used in object oriented settings including education where OOP is typical (see
introductory instruction and
standardized tests as well as
industry certificates). Our current perspective:
- We do not wish to force users into a strict object oriented setting like through forced subclassing.
- We want to be a good participant and follow best practices in an educational setting to model techniques in line with class materials.
- We want students with some experience to be empowered to both read the Sketching codebase and to, when they desire, contribute to it.
- The Python standard library itself frequently uses objects (csv, sqlite, etc) so we expect programmers to need to interact with "class-based" code even if they aren't writing it themselves as they have to encounter it in their broader Pythonic journey.
Therefore, this project reaches a compromise: its exported types should generally follow OOP but should not force use of classes in client code. For example, it should support functional code through callback registration instead of subclassing.