What is the future of Processing Python Mode?

What are the current plans for the future of Processing Python Mode or, alternatively, for a Python package based on the core ideas of Processing, such as p5py, but that is as easy to install as Python Mode? See:

As we know, Python Mode is now available for Processing 4. However, it is still based on Jython, which is Python 2.

The book Learn Python Visually (2021) offers many fine examples of sketches designed for Processing Python Mode. At the same time, it is compatible with Python 3. The great variety of topics covered in the book can each serve as starting points for an equally great variety of larger projects.

It would be comforting to be assured that if we continue to devote energy to developing sketches in what is currently Processing Python Mode, these sketches, with little or no modification, can be carried forward into future environments based on Python and Processing. With the future in mind, would it be best to continue to use Processing Python Mode, or to port our current work to p5py?



1 Like

Thanks for the link, @GoToLoop.

Granted, it may not be a major inconvenience for users to translate between Python 2 and Python 3, as they do their work and create sketches, especially for those of us who have used both. But I would like to also consider the question as it relates to the potential future creative coding user base, as well as the existing one, ranging from kids and artists who may not have had any previous exposure to programming, to those who are already immersed in creative coding, and already have lots of experience translating between Python 2 and Python 3.

Python Mode for Processing is a great feature that is so easy to install, and offers a nice convenient development environment. It would be great for users with varied levels of experience to be able to do all their work with Python 3 code, both inside and outside the Processing environment, without worrying about translating between Python 2 and Python 3. If Python Mode for Processing were upgraded to Python 3, then kids and others who are just beginning to enjoy coding could just take Python 3 and run with it, rather than having to be concerned with such details as the fact that the / operator and other features that they learned with Python 3 won’t work the same way in Processing Python Mode. I know that upgrading Python Mode to Python 3 is a challenge, and am not asking the question out of impatience. Rather, the question in the title of this thread is just meant to seek an update on the current status of the issue. :smile:


The py5 project looks very promising to me. To quote the py5 website, “[py5] makes the Java Processing jars available to the CPython interpreter using JPype.”

The p5py project approach is to write a Processing clone from the bottom-up in Python. py5 takes a similar approach to Processing.py/Python Mode, employing JPype instead of Jython. JPype supports Python 3.8+ and can handle Python libraries with C extensions (hello, NumPy and Pymunk!)

py5 opts for snake_case over camelCase (i.e. rect_mode over rectMode). There are some other differences/improvements to Processing.py, too; there’s also work on a translator for Processing.py–>py5 code. Oh, and, py5 runs in a Jupyter/notebook environment :slight_smile:

To emulate the PDE experience, there’s the Thonny py5-mode plugin – think: the excellent beginner Thonny IDE configured with py5 for a Processing-esque experience.

I suspect it’s possible to integrate py5 into the PDE, Python-Mode-style, but this will require some work …


I believe that’s the single most serious deviation between the main Processing flavors (Java & Python modes, p5js, pjs) and other minor 1s.

They should seriously consider adding camelCase aliases for their API so we can more easily convert sketches from 1 flavor to another.


Oh –

I should probably note the __future__ module here for future-proofing Processing.py/Python Mode (Jython) sketches.

from __future__ import division

print(5/2)  # displays 2.5

@GoToLoop Python Naming Conventions (Detailed Guide) - Python Guides I believe that if you are writing python you should stick to snake case (or with ruby). I think it is daft to ape java/processing. You should also learn the python ways of doing other things the python/ruby way (they can be both more elegant and efficient).

1 Like

Folks learning Processing as a “language” will have contact w/ sketches using lowerCamelCase mostly.

You shouldn’t underestimate familiarity when we have a library which is available across multiple programming languages if your aim is for your library to succeed within Processing’s ecosystem.

We need to bend a particular language to Processing’s style and not the opposite!

Even Processing’s Java Mode bends Java syntax in such a way that folks don’t even realize they’re using Java underneath!

p5js flavor has its “global mode” style which literally dumps its whole API in JS’ global context, which is anathema for JS libraries!

My advice was simply to have an API which has both lowerCamelCase & snake_case styles as alias.


@GoToLoop Sticking to language specific code styles also has the advantage that you can use a linter to statically analyze code, I use rubocop for my ruby-processing projects, similar linters are available for python.

1 Like

For serious development a proper IDE w/ add-ons such as a linter is the way to go.

But for the majority of Processing users who create simple sketches via Processing’s IDE (PDE) or online web editors I don’t think linters are that relevant.

1 Like

Thanks for the updates, @tabreturn, @GoToLoop, and @monkstone.

The above quotes and associated commentary regarding coding conventions and linters would make for a very interesting and relevant discussion. So that the content doesn’t get buried, and therefore lost within this thread, which has a title that doesn’t reflect these issues, it might be a good idea for someone to initiate a discussion regarding these topics within the Processing / Development category.

1 Like

This may also be a possibility. Curious if anyone has tried with Processing core JARs already? Graal Python


Hello! I am the creator of py5.

The goal of py5 is to create a version of Processing that fits in the Python ecosystem. It was not intended to be a drop-in replacement of processing.py or any other version of Processing. I talk about the goals and the differences here. That whole discussion thread might be interesting to you.

There are bigger differences between py5 and processing.py than the camel case / snake case difference, so even if py5 used camel case, there would still be work to be done to convert a processing.py sketch to py5. However, I understand that someone would want to make that conversion, and having to manually change camel case to snake case everywhere is rather daunting. To assist with that, there are some translator tools that might help you. Currently there is a bug but overall the functionality is in good shape. Eventually we will write some documentation that will help you with this by pointing out the changes that the translator is not able to handle on its own. I’ve used it to translate other people’s processing.py code and with that tool I was almost always able to get it working without too much effort. There is room for improvement in the translator. If you’d like to help out with that, we’d welcome your contributions!


Interesting. I had not heard of GraalVM or Graal Python. I started reading about both. The github page makes it sound like it is still very much a work in progress. I will keep an eye on this, I would like to see how the project develops. If they get to the point where it has wider coverage of existing Python libraries I would consider adapting py5generator to create a version of py5 that can run with Graal Python.

1 Like

Thanks, all! There’s a lot of interesting dialog here. Some of it relates to the varied cultures, or Zens among the different programming languages represented.

There’s a spectrum of possibilities regarding the degree to which development can balance the accommodation of these Zens with the benefits of cohesiveness within the Processing Community at large. Where along the spectrum do you each land with regard do these issues?

Some, but not of all of these issues might include:

  • camelCase, snake_case, and the like
  • a single IDE with modes, or separate ones
  • a divergence of a available functions and methods, with each set tailored to the desires of the programmers different languages

EDITED on February 8, 2022 to make minor adjustments to punctuation

1 Like

As you will have guessed my take is that each language has its own paradigm and it is beneficial to go with that. Taking ruby as an example, everything is an object, and ruby blocks (closures in other languages) are a core part of ruby. Say you wanted to print ‘hello world’ 10 times it as simple as:-

10.times {puts 'hello world'}

Objects and methods are interchangeable so we’ve needed to create workarounds for mousePressed method and mousePressed value.

# method
def mouse_pressed
   # user provided block
end # NB all ruby methods return something
# value
mouse_pressed? # returns a boolean by ruby  convention
1 Like

“camelCase, snake_case, and the like”

Can’t we have our cake and eat it too? As suggested earlier – aliases to support both conventions, maybe a module one imports to enable this?

“a single IDE with modes, or separate ones”

Again, can’t we have our cake and eat it too? Processing.py plugs into the PDE (see Python Mode), but the command line version means you can wire it up to any IDE, and by extension, create plugins for other IDEs.

I’d add that support for browser-based environments is vital – like py5 notebook support, pyp5js, and other projects that provide a Python+Processing environment for the Web. Also, I appreciate that a beginner can begin with ‘static’ mode, advance to an animated sketch (with setup() and draw() functions), then extend Processing with 3rd-party libraries. That’s an excellent progression for a beginner and valuable for someone more advanced who can select a ‘mode’ depending on what suits a task.


Hey @tabreturn , I’m currently using Processing.py but am very interested in both py5 and p5py. Is one of these solutions more suitable than the other if I want to integrate sketches into a webpage?

1 Like


(this should probably be a new topic, but I’ll provide a brief answer here)

I’d say pyp5js sounds the most suitable for that application – but it depends …

Here’s the general concept: with pyp5js, you write Python sketches and it ‘compiles’ (converts) those to p5.js (JavaScript); then, you can embed the sketch like any p5.js sketch.


Thanks ! Sorry for hijacking the thread, I got excited seeing someone talking about these two. l’ll make one when I need more precise information.
Btw: py5, p5py, and now pyp5js… Is the community trying to get the newbies confused? Because it’s working.