Hi Jeremy!
I’ve got so excited about your work with the Rosetta examples…
I have created a category there for Processing_Python but now I’m not sure I should have done that… maybe marking using this would be best:
=={{header|Processing}}==
===Java===
<lang java>
...
</lang>
===Python===
<lang python>
...
</lang>
What do you think?
Also I have forked and modified your repository to make a Python mode version… but again, not sure it’s a great idea 
Cheers!
Alexandre
Hi Alexandre – thank you so much – I’m very excited that you are interested, and would love to do things with Python mode as well.
Two great questions. Do you want to discuss them in private here, or should we talk about this in an open forum thread under Development or Project Guidance or whatever?
Sure, please open a public thread where you feel is the most appropriate place!
Okay, so, two issues here.
I don’t have a definitive answer, but I think it should simply be separate.
=={{header|Processing}}==
<lang processing>
...
</lang>
=={{header|Processing.py}}==
<lang processing.py>
...
</lang>
…and there should be a Processing.py language page on the wiki that says something like “Processing.py is a Processing mode. It is a special Python 2 dialect that runs via Jython on JVM, with built-in direct access to the Processing (Java) API.”
The basic reason is that the purpose of the wiki is to compare the same task in different language / syntaxes / modes. For that purpose, it might make sense to make Processing.py a subheading under Python (python2, python3, processing.py) but it probably doesn’t make sense under Processing.
There has long been some ambiguity about whether to call it Python Mode for Processing, or Processing.py, or both (the website and reference material headers do). For the Rosetta Code wiki I would recommend listing it under Processing.py – because languages are listed alphabetically, and that way the two are next to each other.
Headers are also used for the generation of automatic indexes – if the mode doesn’t have its own language header then some things become very hard to track – like looking up what has already been done across the site.
I’m less certain about lang tags. I think that they should be specific – processing, not java, and maybe processing.py, not python – but I need to look that up.
Following up – I think I need to look into this a bit more. JRubyArt, for example, is listed on some pages as a library under Ruby, and it appears to be both a subcategory of Processing and its own category.
They don’t work in the same way, of course – Processing.py is not a Python library, and you can’t import it into Python 2 or 3 – but how to frame it for wiki users seems like there are several options.
Regarding the second issue:
I think that a Python mode version of the Examples is a great idea.
Right now the repo is used to build an Examples package for distribution through PDE Contributions Manager. It is then listed under Contributed Examples. I’m not sure – can this be done for Python mode as well? And if so, can the python and java examples be one Contributions Manager package, or should they be two separate packages?
If two separate Contributions Manager packages were required then it might make sense to use two repos. This is because PDE sources.conf uses the github /latest tag to find the latest release – if we did that, we would have to re-release both the Java and the Python packages together every time, otherwise one would disappear.
However, if they can be bundled together in one repo, I think that would be best, and we can restructure the files / the release scripts accordingly.
Hi Jeremy!
This is so confusing 
The language tags, as instructed by Rosetta Code documentation, should really be java and python because they are invisible to users and are just used for rendering code with syntax coloring.
I have made a page called Processing_Python that covers more or less the content you described. Personally I don’t like Processing.py as a name… It is rarely used. The modes are called Java, Python, Android, etc.
If you ask me I would put it under Processing with the mode name as if a sub-category. We can even imagine p5js if someone would like to contribute with it.
On the second issue of the Contributed Examples package… I think we could have a single repo.
I’ll make a test and get back to you
If you agree with having folders named after the “modes” in your repo… (I know it is a bit ugly…)
But have a look:
Hmm. Take a look at the Coding Creative example set. If you open a new sketch in Java mode and then open the Example window (Java Examples), it only displays Java examples. If you open a new sketch in Python mode and then open the Examples (Python Examples), it only displays Python examples. Seems like that is the structure we want.
Wow! This is way more elegant… I’ll try to understand how it’s done then.
UPDATE: I have to say this is not without glitches… Refusing to open Java examples for me 
SECOND UPDATE: It is not done 
Curses, I’m wrong. That is a python-only example set. It just had a sketch at the beginning that also looked like Java.
It looks like there is no mechanism for marking example sets by mode. And examples show up even in the wrong mode example window! Your marked subfolder idea might be the best one.
The other option is to have two example sets, and so two repos… I’m not sure which is best. I’m tending to the subfolders on a single repo/package because it will be less duplication of work.
This makes sense to me. The example files are tiny, so it shouldn’t bother people getting an extra files that they won’t use. We can say “for Java and Python modes” in the description, and then have
/Java/
/Python/
In fact, @kll already mentioned that it was confusing seeing them while in p5.js mode.
Looking at how the PDE Examples menu works, it seems like this is what happens:
OK!
@jeremydouglass, I’ll try and make a PR adding the Python mode examples that I have made (not many to be honest)! Please advise me if I’m doing anything wrong!
@villares – give me one second, I did a reorg last night and haven’t pushed it yet. I can share that branch now and see what you think – unless you already started (ack, duplicate work)
hahahaha … never mind the duplicate work! I’ll defer to your wisdom any time.
(Yes, I’ve sent a Pull Request a few seconds ago)
I see the PR – it looks really great, but I would like to separate the base reorg of existing files into a separate commit from your awesome new sketches. Why don’t you let me make the base reorg commits right now, then you can add a pull request for all your new sketches in Python. Does that sound good?
(I’m really grateful for all you are doing on this, by the way!)