Python sketches are not Pythonic

[ulgens]

Sorry for the vague title, feel free to update it.

Using https://github.com/processing/processing-examples-mewnala/blob/6e416d80852ee9e147b70ae93cbf8f6dda871ba3/Basics/Structure/Redraw/Redraw.py as an example, a mewnala sketch structure and common techniques has several issues that makes it less ideal as Python code:

• Sharing state between frames requires the use of global
• Even when wildcard import is removed, some variables are injected at the runtime and linters catch them as "undefined":
  • mewnala: mewnala.math, width and height is still being reported as undefined syntax error on VS Code #150
• setup function is not meaningful, the same results can be achieved just without. Using setup to initialize variables etc. causes even more undefined issues because how scopes work in Python.

As an alternative, a class based approach can solve all these issues:

from mewnala import (
    Line,
    Sketch as BaseSketch,
)

class Sketch(BaseSketch):
    def __init__(self, width=640, height=480):
        super().__init__()

        self.width = width
        self.height = height

    def setup(self):
        self.size = (self.width, self.height)
        self.stroke = 255
        self.loop = False

        self.y = 180

    def draw(self):
        self.background = 0

        self.y -= 4
        if self.y < 0:
            self.y = self.height

        line = Line(0, self.y, self.width, self.y)
        line.draw()

    def mouse_pressed(self):
        self.redraw()


if __name__ == "__main__":
    sketch = Sketch(width=1920, height=1080)
    sketch.run()

No more magic imports, no more undefined variables, and now the sketch has a Python-native syntax feel much more natural comparing to the previous version.

I removed the setter function calls too, it's a Java-native pattern and feels weird with Python.

We can go one step further and eliminate the setup() What does it do for the sketch can be covered by __init__ in a class context.

[ksen0]

I am not involved in this particular project in any direct way, just watching out of curiousity and would be happy to try it out at some point. But in my opinion, as primarily a python coder since ~2018, I personally prefer the original sketch. The reason I would use this for art would be with the express purpose of bringing in Processing/p5 patterns and making them available within python. Processing/p5 libraries do have patterns between them that sometimes diverge intentionally from the host languages, and, for me, that is a benefit.

[ulgens]

To be frank, the original code and setup/draw structure feels familiar to me too but they don't work with Python / Python tooling. mewnala already does some behind-the-scene operations to inject variables like height - width, and the overall approach with setup() doesn't match how scopes work in Python - requires even more custom operations.

Another example I can use to summarize the problem is https://py5coding.org/content/py5_modes.html#imported-mode vs https://py5coding.org/content/py5_modes.html#class-mode . Right now, mewnala sketches follow "imported mode". To be able to edit a "imported mode" sketch with VSCode or Pycharm and have a decent experience, the IDEs need a plugin. class mode works just fine regardless of the tooling.

Processing/p5 libraries do have patterns between them

I support the intention here, but I'm not sure it's the case. With the "class mode"-ish alternative I recommend, we would still have the setup / draw structures and the same concept of sketch - so no lost on Processing/p5 patterns. The difference would be that those patterns will be implemented using Python-native approaches and will work fine with Python; instead of using Java-native patterns that are not supported by Python tooling.

sometimes diverge intentionally from the host languages, and, for me, that is a benefit.

I'm missing the benefit with the examples above. Python is a powerful language/ecosystem, and creating broken Python code that works only with a very specific tooling is a significant loss IMO. If we want p5/Processing people to use the patterns they already know, in other languages, "class mode" already provides it but with an important extra: Python devs can start using Processing, while using the best practices of the language they already know. Otherwise, we are limited with Java-native patterns that is not known and/or used by Python people, and a very limited tooling. My honest take here is that this limitation defies the purpose.