I know there are different implementations of Python besides CPython: JPython, IronPython, PyPy, boost::python (are there others?)
I wish to know if they are the same from the point of view of a script/module. By this I mean if all of them uses the same language constructs like CPython (of course taking into consideration also version differences) and if they use the same Python Standard Library’s modules.
The most exciting non-standard Python in my opinion is Pyodide, but it still uses C. MicroPython and CircuitPython have a signifiicant user base. RustPython is being developed too. Are Jupyter, IPython and Sagemath implementations, or just different packages?
Anyway, I’ve worked with Iron Python a lot for a Rhino/Grasshopper plug-in.
The main differences between Pythons beyond CPython, are the lack of C-extensions, e.g. Numpy etc. and lack of modern syntax (even if you only use the non-obsolete Python from those you mention, PyPy (Boost::Python is a library, not a Python), only Python 3.10 syntax is supported).
It’s definitely possible to write implementation independent code by keeping it high level and minimising dependencies, and only using pure Python libraries, e.g. PyCryptodome over Cryptography, and foregoing modern bells and whistles like match. This is less work than writing Python 2/3 compatible code in my opinion.
It’s unusual for there to be a problem with simple code, especially well written PEP8 compliant Python code, but there are definitely differences in the realm of implementation details.
For example, the most devious bug I ever fixed was causing corrupted Shapefile headers in Iron Python, because the old calling application used del to call a .close() and write the header, instead of using a context manager. That was actually no problem at all in CPython, but the Garbage Collector in Iron Python is not predictable. In particular, the Iron gc did not run before the rest of the Shapefile was written, so essential meta data was never written to the header, and the default weird byte string was readable as a valid integer for the shape type field. Luckily it was -13 million or so, and not a value between 0 and 14, or I may have never figured it out.
If the caller had only written clean, modern, PEP8 code (or even if they’d just used a context manager over del), there would’ve been no problem at all.
They can’t be called Python if they do not implement essentially the same language. (ISTR there was a bit of tension over MicroPython not wanting to implement str as well as the core developers wanted in its early days, long since resolved.)
Different implementations are likely to support additional features and compiled libraries (e.g. Jython can import Java packages as if they were Python modules), and not support others (e.g. not be able to import packages written in C). Versions may lag a bit too. Or a lot: the released version of Jython is stuck at 2.7 sadly.
Nobody wants to re-implement the standard library, so where it is in Python, implementations generally adopt the same code (for their version of Python), with only the divergences forced by the differences already mentioned, and history. This can be quite a bit of divergence in the implementation, although the same behaviour is always intended.
OK, but what about embedded Python(-s)? If, for example, I want to write scripts for my game in Python (but the engine of my game in any other language), then does it means someone may use that fact and write a malicious code (like, a code that connects with an Internet server and sends sensitive data there)?
Embedded Python in an app isn’t going to automatically make a user’s machine insecure. An attacker needs to access the embedded Python, and get it to run their payload some how.
So take care not to do anything obviously stupid like running exec with save game data.
However, if your game supports plug-ins or mods, and allows them to run Python scripts, then yes third parties can attack your users, as you have designed your game to contain an arbitrary code execution vulnerability. It’s not a bug, it’s a necessary feature for plugin and mod scripts to work. Users then need to be as wary of third party plug-ins and mods for your game, as they are for any other game.
You could remove anything obviously dangerous, e.g. os.system. I don’t know much about embedding Python, but is it possible to sandbox it, so it can only mess with your game stuff, and can’t reach the host OS?