py2many test cases

[jayvdb]

I am looking for a python to JS implementation to run within or alongside https://github.com/adsharma/py2many , and running pj on the tests in https://github.com/adsharma/py2many/tree/main/tests/cases I found some issues, that I thought worth sharing. See metapensiero/metapensiero.pj#61 for the same in an alternative project.

I initially tried with the PyPI release, and found it doesnt support AnnAssign very well. Using master works a bit better, but still fails https://github.com/adsharma/py2many/blob/main/tests/cases/rect.py with "Cannot convert AnnAssign nodes with no assignment!" due to using dataclasses.

Another set of tests fail due to no "Set", which is already raised as #24 .

https://github.com/adsharma/py2many/blob/main/tests/cases/exceptions.py is an interesting one -- most Python transpilers dont handle this, and pscript does quite well, except it doesnt detect the divide-by-zero, as this returns Infinity on JavaScript, not an exception.

Also a special mention, bitops.py works correctly, where most Python->JavaScript transpilers cant do this (and often wontfix it).

Other failures:

• comb_sort.py, Cant import math.floor
• byte_literals.py: "No Bytes in JS". Isnt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer good enough?
• coverage.py: len(Dict) is converted to object.length, which returns undefined
• infer_ops.py: Cant import ctypes. Could be ignored like typing. e.g.

  pscript/pscript/parser1.py

  Line 853 in d239a23

  if node.root == 'typing':

[almarklein]

PScript does not claim or try to be fully compliant with Python. E.g. annotations and imports are out of scope.

[jayvdb]

Well, most Python-to-JS transpilers do not try to be compliant, wontfixing various incompatibilities at the whim of the main developers preference, and the ones which do have a stated goal of compatibility are still no where near PyPy in terms of compatibility, and either emit horrid JS or have a huge runtime layer. So far, pscript looks closest to my needs, which are a subset of py2many's capabilities, and pscript handles many parts of Python syntax/semantics better than py2many currently does.

The lack of set is a deal breaker for me, but #24 suggests that you are open to set being implemented.

The other item in the Caveats which may effect me is "Keys in a dictionary are implicitly converted to strings", but I havent investigated this sufficiently to know whether the current implementation breaks my use-case, and/or whether I can work around this in a way that is reasonable.

The docs cover the div-by-zero being JS Infinity. I can live with that, but I would be happy to attempt fixing it if possible. The reason is that Python code doesnt have infinity, so it is hard to write PScript code which is valid Python and JS and handles div-by-zero.

As the PScript is already using Math.floor, and other functions which are common between math and Math, it seems like a subset of math might be supported without any need for real imports. But it looks like I could support these in a pscript wrapper if pscript doesnt want these.

I dont need bytes at the moment, but I will in the future. If you agree ArrayBuffer is close enough to use as a base, we can create an issue about it. Otherwise I can handle bytes in a pre-processor.

The len(Dict) problem I found appears to be a bug, or an omission from Caveats if it is a minefield to solve it. I am not using this feature, so it isnt high on my priority list, but I would be willing to try fixing it unless it is already known to be a hard nut to crack. This would solve the py2many coverage.py test case, which is quite important if I was to make pscript the official implementation of JS for py2may. Alternatively, I could move len(Dict) to a separate test case.

I raised ctypes not because I think pscript should support imports or annotations, but because ctypes has a bunch of attributes which are often imported only to be used as part of annotations, and the import node can simply be ignored, as the annotations are already being ignored. Again this can be done in a pre-process phase if you are opposed to it being part of pscript.

fwiw, there are other parts of py2many test suite which fail, but were not raised here because the test suite is designed to have each language supporting only a subset of the test cases, so each language transpiler can develop separately, and skip various functionality which is hard to translate or undesirable.

[almarklein]

Well, most Python-to-JS transpilers do not try to be compliant,

To be more precise, I see PScript more as a way to write JS with a Python syntax. Some incompatibilities are "deliberate", e.g. 1/0 producing inf. And then there is performance. In Pscript I don't want to go all the way in terms of compatibility if it goes at cost of performance. Of course this is usually a compromise.

These two "guidelines" have resulting into a tool that is relatively useful. Relatively Pythonic while still being fast. It has also resulted in a tool that can be confusing, tries to be Pythonic but you have to remember where it's not :) Personally, I have grown to believe that running Python in the browser will always be awkward one way or another.

---

The lack of set is a deal breaker for me, but #24 suggests that you are open to set being implemented.

Yes, I having a set makes sens, though it will be limited in functionality.

The other item in the Caveats which may effect me is "Keys in a dictionary are implicitly converted to strings",

This is something that JS does with object. Would be hard to solve unless you completely re-implement dict.

I dont need bytes at the moment, but I will in the future. If you agree ArrayBuffer

Yeah, I think we could convert literal bytes to ArrayBuffer or Uint8Array and e.g. implement encode/decode.

The len(Dict) problem I found appears to be a bug, or an omission from Caveats if it is a minefield to solve it.

It should be in the caveats, but it appears that it's not. This is a performance thing. Though I am open to considering overloading len() so that we can fix it. We always have PSCRIPT_OVERLOAD=False where needed.