Hello,
On Wed, 2 Dec 2020 09:53:07 -0800
Christopher Barker <python...@gmail.com> wrote:
> 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.
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.
>
> -CHB
[]
--
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/FOYIAXD4ZTIRBWQRIV7A2DAR3KYFONZE/
Code of Conduct: http://python.org/psf/codeofconduct/
