I find the p5py maintainers decision to forgo any attempt at API compatibility with Py.Processing annoying. Sometimes I think about writing wrapper functions as a compatibility layer for it…
I put daily effort on didactic materials for my students using Processing Python mode and a huge body of examples, like Jeremy Douglass’ Rosetta Code collection, goes to waste if p5py succeeds (as I hope it will) and Python mode dwindles away (as I’m afraid it might).
So @jeremydouglass suggested we might want to discuss this idea/comment here
I agree that the basic decision to make the p5py API as pythonic as possible (rather than as cross-compatible as possible) can create some problems. This is particularly difficult for new modes which have little documentation (so students are more likely to need to rely on examples from other modes, which use the different API). If learners are trying to adapt materials from other modes into the new mode, being different makes it harder.
That said, there can be some advantages to being as pythonic as possible. The core devs might have other audiences in mind, or see other advantages in a break with tradition–it might be worth asking. JRubyArt and Processing.R also embrace some aspects of their language that are very unlike the Java API.
I really like your idea for a wrapper / compatibility layer – it might be the best of both worlds. One that you could dynamically load or import might be even better than a fork. I’m thinking of a design along the lines of from __future__ import print_function – such as from p5 import api.
This might be a good conversation to have with the core devs.
Yes, it is mostly unfunded open source – being overwhelmed is pretty normal for beginners and vets alike.
Good idea about a proof of concept. I believe that Sam moved ahead with a P4 prototype by just developing a public fork – then it didn’t matter whether or not Ben had the bandwidth to review a branch on the main Processing repo – so that could also be a model. But sometimes it is nice to try to integrate or at least ask first before forking.
Maybe we could start with an API matching list? A lot of things are just changing underscores to camelCase, right?
It looks like the tuple interface for positions ins now optional!
So now we have a much easier job…
I started with the inputs. Help with implementation of the import mechanism would be appreciated.
mouse_moved(): mouseMoved()
mouse_pressed(): mousePressed()
mouse_released(): mouseReleased()
mouse_clicked(): mouseClicked()
mouse_dragged(): mouseDragged()
mouse_wheel(): mouseWheel()
mouse_is_pressed: mouseIspressed # like p5js, but I would prefer mousePressed if possible
mouse_is_dragging: mouseIsdragging # this is new, so I'm not sure
mouse_button: mouseButton
mouse_x: mouseX,
mouse_y: mouseY
pmouse_x: pmousey
pmouse_y: pmouseY
key_is_pressed: keyIspressed # same issue as mouseIsPressed/mousePressed
key_pressed(): keyPressed()
key_released(): keyReleased()
key_typed(): keyTyped()
If I recall correctly, it was only with push_matrix(): before? Nice! I’m thinking this will make p5py --> pyp5js easier (for running Python sketches in web browsers)
camelCase, right?