On Wed, 2 Dec 2020 09:53:07 -0800 Christopher Barker email@example.com wrote:
On Wed, Dec 2, 2020 at 6:11 AM Paul Sokolovsky firstname.lastname@example.org 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.
No, it's "restricted" version of Python, that's what "R" in RPython means. "Flip around" is very related however. In a sense, RPython and "strict mode" approaches are opposite: RPython starts with a simple subset of Python (and let you write a full Python in it), while "strict mode" takes a full Python and tries to take away from it as little as possible to achieve the desired effect (optimizing name lookups in this case).
I hope you agree the difference in approaches is quite noticeable.
You mentioned that it was frustrating that it does not have a properly written (or any?) spec.
It definitely has some docs. Yes, I would say they're not ideal.
but it DOES have an implementation, so maybe you can write the spec instead of the implementation :-)
For that I would need to use RPython. I considered that circa 5 years ago, and of course explored it. I "liked" what I saw, sure. But I "wasn't happy" with what I saw.
There seem to be hints that I may be making this "strict mode" thingy because I wasn't aware of PyPy/RPython. But actually it's the opposite: being aware of RPython and knowing enough about it is what causes me to explore a different direction.
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'm an open-source guy all along, and consider duplication of effort to be one of "mortal sins" of the open-source. Beyond that, I'm also a lazy dude who prefers to spend his days on the beach and not in the front of computer. Neither I ever was mad enough to "write my own thing". I wanted to write a small Python literally for decades, but instead studied what other people did/do. I for example rejected TinyPy as a base, due to its source code quality (but its spirit is very high, I consider my Pycopy to be spiritual successor of it). Then when MicroPython was announced on Kickstarter, I literally talked its author to open-source it a half-year earlier, and contributed to it for several years, literally having written a third of it.
It's the same with the "strict mode". While there's a bunch of "original research" in it, it's all based on (or related to) ideas expressed by other people, which I made sure to have studied before proceeding to implementation (references are given in the proposal).
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)
I fully agree, and fully understand that. Again, that's a reason to explore a different direction, not against it. ("That area is already covered by good people, let's look elsewhere.")
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.
It's not, and that's disclosed right away. If anything, lack of "too beautiful docs" is related to PyPy's project desire to not make RPython a standalone, general-purpose dialect of Python. Nor it's comparable to a "normal" Python, usually presented as "C-like subset" of Python. (I'm writing this by memory and don't have references at hand, so specific terminology used by them may be different).
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
I remember that very well, and that's another point I don't agree with.
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.
I never met a Python user who said something like "I want Python to be slow" or "I want Python to keep being slow", so we'll see how that goes.