On Sun, 8 Sep 2019 at 20:05, Mark @pysoniq email@example.com wrote:
We are just going into beta, so we are not yet in a position to run the tests you mentioned. When we go to release 1.0, we will be able to do that.
Your claims are (currently) inaccurate, then. I suggest that you avoid making them until you can demonstrate their accuracy. Otherwise, you absolutely give the impression of doing a commercial sales pitch, which is not likely to get a positive reaction here (as you've seen).
As far as limitations, the Technical FAQs cover as many limitations as we know of now. For example, under "classes" we mention that we can't do a derivitave class unless the base class is in the same .py file. We also mention that classes without the "self" word are not supported. We don't currently support print statements or async io.
Well, not being able to handle print statements seems like a major problem. Ignoring the fact that print is no longer a statement, but simply a builtin function, and assuming that you mean you don't support IO (because there's very little other interpretation I can give to you not supporting the print function), I can't see how I could usefully write a project without being able to use print()...
There are other limitations in the Tech FAQs, but hopefully they are not significant.
That's for the people you're asking to get involved to judge. Listing them in an easy to locate place (and providing a direct link to the listing - not forcing people to navigate your website) is hardly too much to ask, surely?
To be clear, this is a project in development and I posted it here to get developer feedback specifically from developers who have a real need to speed up their project. For some projects, speed is not important.
I have a hobby project where speed is important (Monte Carlo simulation of games of chance). But without print, you're of no use to me. Even with print, I expect end users to code their game rules using Python, so *precisely* what the limitations of your interpreter are directly affects my user interface. I certainly have no intention of testing my code under your implementation if doing so is only likely to help you deliver a closed source product that I (or my friends) would need to license to run my program.
PysoniQ is not currently a commercial product, so this was not intended as an advertisement. I wanted to get technical feedback, bearing in mind that for reasons stated earlier it's not open source and the source is not published. As mentioned earlier, we are open to the idea of open source if we can find a large enough community of volunteers with the skills to translate Python directly to assembly language without using an intermediate representation or a third party compiler like LLVM.
Your current approach doesn't seem well judged if you're interested in attracting a "community of volunteers" :-(
From another post:
"Mypyc supports a subset of Python," whereas PysoniQ is not a subset and uses only standard CPython code, without alteration.
You keep saying this. OK. Here's a simple Python program. Do you compile it to correct assembly code that gives the right answer?
assert ((-80538738812075974)**3 + 80435758145817515**3 +12602123297335631**3) == 42
How about this one:
import math import sys def f(): return 42
sys.modules['math'].sin = f assert math.sin() == 42
If you want to claim that you don't support these "yet", when will you? Until you do, please stop claiming that your product "is not a subset".