GSoC-2014: processing.py mode

edited March 2014 in Summer of Code 2014

Hello!

My name is James Gilles. I spent some time last summer working on python-mode-processing, a PDE-mode for Python which occasionally works! I'd love to spend this summer reworking it and/or creating a new, actually usable mode. This would entail:

  • Using processing.py to run code, rather than my own hacky solution. I spoke to Jonathan Feinberg a few months back about this and we both agreed that merging the projects would be a Good Idea, although I haven't had time to work on it.
  • Getting syntax highlighting & formatting working properly. This is very important for learners, and just generally nice. Marco Gillies (no relation) is already working on this, which is awesome.
  • Creating documentation. I'm thinking full online documentation, along the lines of java-mode or processing.js. (This is already partway done - processing.py has the full set of Processing examples).
  • Handling exporting sketches properly. This shouldn't be too hard, hopefully.

Seeing as a Python mode is listed as a 'quick project' on the wiki, I have a few more goodies I'd like to implement:

  • An REPL. Python is great for interactive use, and it would be awesome to be able to talk to a sketch while it's running. (This might interact weirdly with Processing's multi-threaded nature, but there should be some way to get it to work.)
  • Pip integration. I'd love to make a slick user interface so that users can install libraries like pandas and sympy without having to mess with the command line. Pip often "just works" with Jython - the exception is cython code, but it looks like people are working on it.
  • Fudging Python globals. Idiomatic Processing code frequently modifies global variables, which python doesn't like - you have to use the "global" statement if you want to change anything. This could be a stumbling block for new users, and I'd like to find some way to mitigate it.
  • Allowing Processing to leave the sketch process running. Python code doesn't need to be compiled, so just resending code to the sketch process works, and is much faster than restarting the JVM & Jython when the user hits "run". (This, along with the REPL, mean that the PDE and the sketch process will be doing some complex communication. They currently talk using stdin/stdout, but I may want to switch to a slightly more refined version of IPC, which I could push back to mainline Processing if people were interested.)
  • Increasing mode support. There are a few spots in the code base that are still hard-wired for Java Mode (the syntax highlighting and keyboard input code come to mind), and I'd like to polish those up.

Does this seem reasonable? Feedback? Suggestions? (Hopefully this isn't too late notice)

Answers

  • edited March 2014

    Hello James, I don't have much experience with processing.py, but what you posted here sounds very reasonable to me, and close to all you need to write your proposal. Check the info from the GSoC FAQ. And yes, the deadline is tomorrow, so not much time left!

  • Answer ✓

    James, please apply. Sounds good. We're excited about this.

  • edited March 2014

    ...Unfortunately, due to me leaving my submission late and misreading the time of the deadline (7:00 UTC, not 7:00 EST), I was unable to apply :(

    I'll still be happy to do the project, though. It's something I want to do, and I don't need to be paid to make something cool.

  • James, I'll be in touch. More soon, there are some gears turning.

Sign In or Register to comment.