Adding PVector wrapper/helper class to pyodide mode

[villares]

My attempt at solving #125
Kind of solves #20 for the pyodide mode

[jvfe]

It would also fix #135 I believe, it would only be a question of substituting p5.Vector for PVector in the example given.

[berinhard]

@villares thanks for your PR and the code looks great for me! But, to merge this, I'll wait until we have something similar for transcrypt interpreter as well.

IMHO, if we can't support this API for Transcrypt, I don't know if we should merge this PR. I mean, one thing is to support something only for pyodide due to transcrypt's limitations. Another thing is to expose helper APIs that works only for one of the 2 interpreters.

I mean, in the long term, this can be misleading to users since pyp5js will have different behaviors and API when they change interpreters. I want to avoid this scenario because it can potentially increase the numbers of new issues and it can pass an image of a broken project somehow.

[GoToLoop]

, I'll wait until we have something similar for Transcrypt interpreter as well.

Which parts aren't compatible? The annotations? Which 1s? The getters & setters?

[berinhard]

@GoToLoop right now we don't have a PVector implementation for transcrypt at all. The user has to use p5.Vector as described in the examples.

So, we'd have to port this class @villares is introducing to work in the current pyp5js.py implementation as well. But the conceptual difference between transcrypt and pyodide (the first generates JS files from Python code and the second runs python code in the browser on top of web assembly) can introduce incompatibilities, such as not being able to implement operators overload.

In my opinion, for transcrypt, we should at least expose the PVector class and its static methods. If we can do that, I think we escape from pyp5js exposing 2 APIs to handle vectors and leave the incompatibilities motivations back to transcrypt.

[berinhard]

@villares can you link the PVector test file from processing.py you're using as a reference? We can use it to discuss what should be supported by transcrypt and what should only be supported by pyodide mode.

[villares]

This escalated quickly!

The tests are here: https://gist.github.com/villares/e639a34eef756beba2f79a55203cd51e

The only incompatible thing, as far as I can see, is the operator overloading that would need pragma flags or other global Transcrypt options that would impact performance (but I can be terribly wrong).

[villares]

So @berinhard, now that we could have #138 on Transcrypt mode, that mirrors most of the functionality added by this PR (except for the operator overloading) do you think we could proceed? Any other objection, or am I missing something else?

[villares]

I see a problem on this PR :(
Testing I saw that the PVector name is not available before setup()
I have to wrap my head again to understand, because it was some time ago...

[berinhard]

Thanks @villares

[felipesanches]

I guess the docs should also be updated because I see it says There are no PVector objects here:
https://github.com/berinhard/pyp5js/blob/develop/docs/index.md#known-issues-differences-to-the-processingpy-and-p5js-ways-of-doing-things-and-limitations