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?
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.
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
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.
@GoToLoopPython 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).
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.
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.
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.
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.
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
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
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?
(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.
