Skip to content

1. Introduction

We have three simple aims:

  1. To better understand how practitioners perceive and use PyScript through evidence-based qualitative research methods.

  2. To identify how we should refine and grow PyScript in response to the practitioner feedback - while clearly identifying and learning from our mistakes.

  3. To demonstrate and embody professional, inclusive and cooperative community engagement as good open-source citizens.

Ultimately, this is an exercise in placing PyScript practitioners (be they commercial customers or open-source community members) at the heart of what we do, so we build something empowering, vibrant and valuable.

Our evidence is of two sorts.

  1. Nine individual practitioner interviews spanning a deliberately diverse range of the practitioner archetypes: learner, educator, engineer, informatician, administrator and hobbyist. Appendix 1 defines these archetypes and the methodology behind them.

  2. A two-part tooling case study with two professors at Tufts University, Chris and Ethan, who together represent an institutional relationship rather than a single archetype (see Section 3 and the case study in Section 5). The first Tufts call gathered requirements around PyScript.com's reliability; the second reviewed TuftsHub, the tool Nicholas quickly built in response.

The individual interviews were semi-structured. Each opened with the person's background and route into PyScript, moved through a recent project and their tooling, probed the bumps in the road, and closed with reactions to community tools and an open "moon on a stick" prompt about what we should build next. Several included a short live coding session; these sessions produced some of the most valuable material we gathered. See appendix 2 for an exploration of UX-related concepts used to inform how we organised, structured and approached the interviews.

A note on method. Jessie and Nicholas planned the interview structure with help from Avery, Anaconda's in-house UX expert, and conducted the interviews together over Zoom. All participants gave recorded consent and provided basic information about their use and impressions of PyScript via a form sent in advance. Participants were recruited from the existing PyScript community: an open call in community channels, supplemented by direct invitations where the volunteers left an archetype uncovered (Anna, our learner, joined this way). Two participants, Nitau and Claudiu, are pseudonyms at their request; all other names are real. Each interview produced textual outcomes: a full transcript, summary and thematic breakdown. As a first analytical pass, these were read by Claude (an LLM), which proposed candidate overarching themes. Everything that followed was human work: Nicholas checked every transcript, cross-referenced between interviews, and wrote and refined the report itself (with, in the spirit of full disclosure, an LLM as proofreader and critic). This is a human-authored report, with an AI used for analytical first passes and editorial suggestions.

A note on the sample. The individual interviews skew towards experienced engineers, with only one early-stage learner and no pure administrator. Claudiu is the closest we have to an administrative or strategic voice, and he straddles the hobbyist and administrator types. The Tufts case study partly offsets this, since it speaks directly to institutional concerns (hosting, authorisation, credentials, cost) that the individual interviews touch only lightly. Even so, broadening the individual sample across all six types is worth doing in future research.