Sketchingpy presubmission

[sampottinger]

Submitting Author: Sam Pottinger (@sampottinger)
Package Name: sketching One-Line Description of Package: Interactive science in Python for browser, desktop, and Jupyter. Repository Link (if existing): https://codeberg.org/sketchingpy/Sketchingpy

---

Code of Conduct & Commitment to Maintain Package

• [X] I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package after should it be accepted.
• [X] I have read and will commit to package maintenance after the review as per the pyOpenSci Policies Guidelines.

Description

This interactive science library facilitates highly custom data visualization and other similar interactive experiences which it supports across headless environments, desktop, websites (WebAssembly), and Jupyter. In other words, Sketchingpy allows the same Python code to be portably deployed across different devices and form factors, achieving a “write once run anywhere” capability for bespoke data rich experiences. Though still under development, it is a central goal to support scientific and educational efforts. For example, I am using it right now for my work at UC Berkeley with example scenarios:

• Highly custom interactive science tool / visualization similar to global-plastics-tool.
• A geospatial visualization similar to processing-geopoint BART visualization.

That said, like D3 or Processing, it is not a charting library. It is distinct from matplotlib in that its central focus is to build highly custom experiences from visual primitives like rectangles instead of using concepts like bar charts as primitives. This allows it to support highly custom visual design potentially not conducive in charting libraries.

Of course, these linked examples are not written in Sketchingpy as the library is just now about to achieve its first alpha. They are included to be demonstrative. Even still, it has a website with demos at https://sketchingpy.org/.

Community Partnerships

We partner with communities to support peer review with an additional layer of checks that satisfy community requirements. If your package fits into an existing community please check below:

• [ ] Pangeo
  • [ ] My package adheres to the Pangeo standards listed in the pyOpenSci peer review guidebook

Scope

• Please indicate which category or categories this package falls under:

  • [ ] Data retrieval
  • [ ] Data extraction
  • [ ] Data processing/munging
  • [ ] Data deposition
  • [ ] Data validation and testing
  • [X] Data visualization
  • [ ] Workflow automation
  • [ ] Citation management and bibliometrics
  • [ ] Scientific software wrappers
  • [ ] Database interoperability

Domain Specific & Community Partnerships

- [X] Geospatial
- [X] Education
- [ ] Pangeo
- [ ] Unsure/Other (explain below)

• Explain how and why the package falls under these categories (briefly, 1-2 sentences). Please note any areas you are unsure of:

The tool offers some geospatial functionality and it is incorporating design aspects to help facilitate its use in introductory computer science coursework.

• Who is the target audience and what are the scientific applications of this package?

Most relevant I think are scientists looking to visualize their work or make their results interactive (“interactive papers”) similar to global-plastics-tool (see preprint). However, the audience does also include students, educators, artists, and data visualization professionals. In addition to facilitating interactive science, it is also trying to serve the creative coding community.

• Are there other Python packages that accomplish similar things? If so, how does yours differ?

This package isn’t a charting library like matplotlib. Instead, it centers highly custom visual and interaction design. That in mind, its clearest counterpart is likely py5. However, Sketchingpy offers some distinctions. First, it has portability across web, desktop, mobile, Jupyter, and server. Second, it includes of some features specific to interactive science like the geospatial tools. Third, it is more agnostic of execution environment (py5 and processing.py, for example, both require Java / the JVM). Finally, consider that some other libraries like processing.py drop members into global namespace which complicates PEP8. Though I understand their rationale, Sketchingpy is also taking care for OOP and standards compliance needs.

• Any other questions or issues we should be aware of:

I am doing a pre-submission because, though it is supporting scientific efforts, it has objectives for computer science education and creative coding which I worry may be out of scope for pyopensci. I hope this may serve the scientific Python community and, as mentioned, I am already using it in my own academic research projects. Even so, I completely understand if this is out of scope. Thank you very much for your time.

P.S. Have feedback/comments about our review process? Leave a comment here

[NickleDave]

Hi @sampottinger, thank you for your detailed presubmission inquiry.

Sketching.py looks incredible, I can tell you've put a lot of work into it, and I'm sure a lot of people will be excited about it.

But I am afraid you are right, and we need to consider this out of scope for pyOpenSci. It's for the same reason we considered #145 out of scope: the functionality is too general. I do see you have on example that uses geojson for maps, but as far as I can tell most of the content in the docs focuses on general visualizations. Please let me know if I am wrong.
If you were to come back at some point and say "we have developed extensive functionality for" (say) molecular structures, or sunspot data, or some other domain, we could reconsider.

But as of now, after discussion we have two editors saying this is out of scope.
Please let me know if that makes sense.

[sampottinger]

Absolutely totally understand. Thanks for your consideration!