On Sun, 8 Sep 2019 at 20:05, Mark @pysoniq <m...@pysoniq.com> wrote: > > Paul, > > 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". Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PT5BO5YK53YEC4VEVOF33HH5RVYQWIFG/ Code of Conduct: http://python.org/psf/codeofconduct/
