On Wed, Dec 2, 2020 at 6:11 AM Paul Sokolovsky <pmis...@gmail.com> wrote:
> Just imagine that if someone wrote previously such a detailed spec, > which I liked - I might implement it now. And if they actually even > provided a sample implementation, I might now code changes for it in the > compiler, and maybe even run a few tests to provide those performance > figures which you and me so much would like! > Maybe flip this around a bit -- it seems that RPython, from the PyPy project is an implementation of a "strict" version of Python. You mentioned that it was frustrating that it does not have a properly written (or any?) spec. but it DOES have an implementation, so maybe you can write the spec instead of the implementation :-) Honestly, I myself have MANY times decided to write my own thing, rather than take the time to figure out what someone else already wrote -- even though it usually takes longer and gets a worse result :-) I have not followed PyPy closely, but I suspect that the lack of a formal spec for Rpython is not laziness, but rather that the entire point of it is to support PyPy, so they want to be free to adjust it as needed, rather than sticking to a a spec (or constantly trying to maintain a spec) Nevertheless, there are probably some really good lessons in there, and it would be very interesting to see if (a version of) RPython could reasonably be used to directly write general purpose programs. Other than the fact that a lot of work has already been done on it, RPython has the advantage that (presumably) its restrictions are there because they have been shown to help performance. Another option would be to build on something like Cython -- taking advantage of the type specifications at run time, without pre-compiling the entire module. NOTE on that: back when there was a lot of discussion about standardizing type hints, I asked about making them work with, e.g. Cython, to get performance benefits. The answer at that time was that performance was NOT the point of type hinting -- i.e. it was designed explicitly to support Pyton's dynamic nature. So it seems adding things like you are proposing with an eye to performance is not really where the Python community wants to go. -CHB > > Getting thoughts like that, most people I know would reflect them on > themselves, and I'm not an exception. So, I post whatever I have for > peer review, and continue. > > > We shouldn't limit the core language > > based simply on speculative benefits that some implementation might be > > able to achieve. > > That's why it's introduced as an *opt-in* feature for *interested* > implementations. > > > > > Paul > > > > -- > Best regards, > Paul mailto:pmis...@gmail.com > _______________________________________________ > 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/KKY7MQVCMQT7V6ZMLEKH4YBB76QIRWV6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/KVBRDIX6E2IW3IPW472WXQ3OPIZICCHO/ Code of Conduct: http://python.org/psf/codeofconduct/
