pypy.org issueshttps://foss.heptapod.net/pypy/pypy.org/-/issues2023-01-26T13:08:35Zhttps://foss.heptapod.net/pypy/pypy.org/-/issues/12Versions of CPython used for speed comparison in pypy.org2023-01-26T13:08:35ZPierre AugierVersions of CPython used for speed comparison in pypy.orgThe main page of pypy.org starts with "On average, PyPy is 4.8 times faster than CPython 3.7" and the figure just below show a comparison with Python 2.7.
Now that more effort is spent on the performance of CPython (https://github.com/f...The main page of pypy.org starts with "On average, PyPy is 4.8 times faster than CPython 3.7" and the figure just below show a comparison with Python 2.7.
Now that more effort is spent on the performance of CPython (https://github.com/faster-cpython), it would make sense to compare with more recent versions of CPython. IIRW, the first version of CPython to include changes from the Faster CPython project is Python 3.11 and so they use Python 3.10 as a base for comparison (https://github.com/faster-cpython/benchmarking-public).
As a result of the Faster CPython project, some people could think that CPython is fast enough so that PyPy is not really useful (an example here https://twitter.com/squidfunk/status/1618522245244284928).
It seems to me that it would make sense in the first page of pypy.org to compare PyPy with Python 3.10 (as the Faster CPython project) (for the sentence "On average, PyPy is ? times faster than CPython 3.10" and the figure) and to also mention the comparison with the latest Python release (nowadays 3.11, which is a bit faster than 3.10). I guess for now the numbers are going to be very close but it's interesting to show that. For pure Python code, CPython is (not yet) as fast as PyPy.
I guess it would be better to avoid a comparison with Python 2.7.11 (as in the figure in pypy.org).https://foss.heptapod.net/pypy/pypy.org/-/issues/10500 errors on speed.pypy.org2021-04-21T10:25:34ZOliver Margetts500 errors on speed.pypy.orgIt seems like `speed.pypy.org/changes` and `speed.pypy.org/timeline` never load. The underlying request just `500`s
![image](/uploads/2342523d8211098c81032e74e5998f89/image.png)It seems like `speed.pypy.org/changes` and `speed.pypy.org/timeline` never load. The underlying request just `500`s
![image](/uploads/2342523d8211098c81032e74e5998f89/image.png)https://foss.heptapod.net/pypy/pypy.org/-/issues/7Rethink website2021-03-01T09:21:46ZMatti PicusRethink websiteAs posted on the pypy-dev mailing list, [here](https://www.dropbox.com/s/r817xirkhcm9dks/pypy.org-0.3-annotations.png?dl=0) is a proposal for improving the website front page, and [here](https://www.dropbox.com/s/hnabjxy4aybfp1y/pypy.org...As posted on the pypy-dev mailing list, [here](https://www.dropbox.com/s/r817xirkhcm9dks/pypy.org-0.3-annotations.png?dl=0) is a proposal for improving the website front page, and [here](https://www.dropbox.com/s/hnabjxy4aybfp1y/pypy.org-0.3.png?dl=0) is the image without annotation. Copying the comments from the annotated site:
- Putting "A fast, compliant, alternative implenetation of Python" in the header you are immediately made aware of what PyPy is, and what it offers.
- Putting "%420 faster on average" in the header shows the power of PyPy
- Highlighting the quote from Guido at the top of the content gives credit to the project and might help aleviate some of the worries the future use might have.
- Adding 4 points, with 4 words. What you get clean and simple. We can link from those to more explicit details.
- Put the the blog posts right at the website, and not have visitors jump back and forth to a blog website (xref issue #3)
- Make the "Download", "Learn More", "Donate" and "Contribute" link buttons.https://foss.heptapod.net/pypy/pypy.org/-/issues/9buid and deploy via CI2021-01-13T05:53:46ZMatti Picusbuid and deploy via CIxref #7 where @markdoerr said:
Consider generating the static html pages by the CI/CD pipeline (I think we discussed that a longer time ago):
So you might utilise the CI machinary to generate the static pages. You can stick with nikola ...xref #7 where @markdoerr said:
Consider generating the static html pages by the CI/CD pipeline (I think we discussed that a longer time ago):
So you might utilise the CI machinary to generate the static pages. You can stick with nikola - of even move to the python doc standard sphinx, like we do here:
https://gitlab.com/SiLA2/sila_python/-/blob/master/.gitlab-ci.yml
which results in static html pages of gitlab:
https://sila2.gitlab.io/sila_python/
It might make changes much easier, dynamic and future proof since every commit in master will automatically generate everything without human intervention.https://foss.heptapod.net/pypy/pypy.org/-/issues/8Migrate blog from morepypy to pypy.org2021-01-07T06:05:07ZMatti PicusMigrate blog from morepypy to pypy.orgIt would be nice to host everything in one place. Then "posting a new blog post" would become "issue a PR to this repo", which might encourage third parties to post about their PyPy experiences. There is a nikola plugin to import blog po...It would be nice to host everything in one place. Then "posting a new blog post" would become "issue a PR to this repo", which might encourage third parties to post about their PyPy experiences. There is a nikola plugin to import blog posts via RSS https://plugins.getnikola.com/v7/import_feed and another one specifically for blogger https://plugins.getnikola.com/v7/import_blogger/. I think the second one should import the comments too?https://foss.heptapod.net/pypy/pypy.org/-/issues/3When we migrate blogs, maybe allow commenting via https://utteranc.es/2021-01-06T08:47:51ZMatti PicusWhen we migrate blogs, maybe allow commenting via https://utteranc.es/It uses github comments as a storage format, maybe we could port it to heptapod comments.
Here is one blog using it https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/It uses github comments as a storage format, maybe we could port it to heptapod comments.
Here is one blog using it https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/https://foss.heptapod.net/pypy/pypy.org/-/issues/2Add content about PyPY's CSP ability (Communicating Sequential Processes)2021-01-04T06:14:53ZBitbucket ImporterAdd content about PyPY's CSP ability (Communicating Sequential Processes)*Created originally on Bitbucket by Anonymous*
Hello.
I am just about to start an asynchronous project. The ASyncio approach, much like Javascript callbacks looks way way too complicated. I much prefer the the model of Communicaint ...*Created originally on Bitbucket by Anonymous*
Hello.
I am just about to start an asynchronous project. The ASyncio approach, much like Javascript callbacks looks way way too complicated. I much prefer the the model of Communicaint Sequentil Processes (CSP), supported by GoLang, Erlang, and maybe (?) by PyPy with Gevent.
I have long been interested in Gevent, but reportedly on cPython, there is a garbage collection bug.
Plus everyone else is using ASyncio. Very hard not to use the mainstream approaches.
Which brings me to PyPy. I suspect that PyPy + Gevent gives me CSP. But I am not sure. Your web site does not mention it. Here is what it says:
◦ Stackless: PyPy comes by default with support for stackless mode, providing micro-threads for massive concurrency.
I have been in the Python community for many many years. I know about stackless. I know about micro threads. Since the Python remote calls are blocking, it is not at all clear from your home page, how to do asynchronous calls from micro-threads. Time to switch to Go. So last night I was reading the GoLang tutorials. Beautifully done, a big brand name, it scales great, but static binding is bad enough to bring me back to PyPy.
Could your home page instead say something like:
GoLang, Erlang and PyPy (with Gevent) support the concept of Communicating Sequential Processes. In contrast, PyPy and cPython’s asyncio as well as Javascript support the concept of callbacks. There are many who believe that CSP is much easier to program than callbacks.
And then a link to a page that introduces the CSP ideas.
The idea here is to compete with cPython by correctly supporting CSP, made famous recently by GoLang. I think that would bring you a lot more users, and eventually more money as well.
Frankly I am not at all sure if CSP on PyPy would work, and be supported. if it does, then you would have a major advantage over cPython, and I would have a very interesting talk for the local meetups and European conferences.
Plus it would solve my immediate problem, and the problem that a good friend of mine is facing.
I look forward to hearing what you have to say about this.
P.S.
By the way, I am the guy who had dinner with the PyPy core developers at the great Italian restaurant at the EuroPython conference.
Christopher Lozinski