Skip to content

PyPy compatibility #22

Closed
Closed

Description

@jcrist

This was raised on twitter, and may be important for some users. Currently msgspec is written as a c extension using some private cpython apis, making it incompatible with pypy. It would be good to have a pypy compatible build, whether through changes to the c extension or through a separate pure python release. Either seems fine to me, provided the result doesn't decrease cpython performance noticeably.

Activity

  1. jcrist commented on Feb 25, 2021

    @jcrist
    MemberAuthor

    I personally don't intend to work on this anytime soon, just flagging it so it doesn't get lost. PRs welcome.

  2. jcrist commented on Jul 13, 2021

    @jcrist
    MemberAuthor

    This project has grown in scope enough that a separate pypy implementation would be more trouble than it's worth IMO. Closing.

  3. provinzkraut commented on Dec 13, 2022

    @provinzkraut
    Member

    Hello there, just wanted to ask if you'd consider revisiting this? I wanted to evaluate Starlite's PyPy compatibility and msgspec is unfortunately a blocker there. Seeing as the project has evolved even more since the original decision, I don't suspect achieving compatibility has become any easier though..

    A re-implementation in pure Python would be a really big task. Do you see any other way compatibility could be achieved?

  4. jcrist commented on Dec 13, 2022

    @jcrist
    MemberAuthor

    This is not something I plan on supporting in a volunteer-only basis (if someone wanted to pay for this, I might be willing to expand support).

    A few reasons:

    • msgspec is heavily tied to the CPython c-api for performance. PyPy does support a subset of the CPython c-api, but it does so in a way that is not very performant, and isn't 100% compatible. We could add shims everywhere that's needed to make msgspec PyPy compatible, but that would muddy up the code, increasing our maintenance burden.
    • Due to how PyPy's c-api layer works, performance on PyPy would be worse than on CPython. Whether this matters is application dependent.
    • CPython is getting faster, reducing the advantages of PyPy
    • Other "fast" libraries (e.g. asyncpg, orjson, ...) also don't support PyPy, and people generally seem fine with that.
  5. Goldziher commented on Dec 13, 2022

    @Goldziher

    This is not something I plan on supporting in a volunteer-only basis (if someone wanted to pay for this, I might be willing to expand support).

    A few reasons:

    • msgspec is heavily tied to the CPython c-api for performance. PyPy does support a subset of the CPython c-api, but it does so in a way that is not very performant, and isn't 100% compatible. We could add shims everywhere that's needed to make msgspec PyPy compatible, but that would muddy up the code, increasing our maintenance burden.
    • Due to how PyPy's c-api layer works, performance on PyPy would be worse than on CPython. Whether this matters is application dependent.
    • CPython is getting faster, reducing the advantages of PyPy
    • Other "fast" libraries (e.g. asyncpg, orjson, ...) also don't support PyPy, and people generally seem fine with that.

    Thanks for clarifying this. I think we are fine not having pypy support.

  6. v3ss0n commented on Jun 17, 2023

    @v3ss0n

    Since pypy 3.-10 (7.3.12) released , and CPyext performance and compatibility was being improved in past recent year , this should be able to fixed. What are the missing APIs ? I had contacted pypy-dev mailing list and linked this. They should be able to help.
    if this can be solved , we can support that in litestar.

  7. mattip commented on Jun 17, 2023

    @mattip

    @v3ss0n I don't think the reasoning in the comment above has significantly changed even for the last PyPy release. As seen in #443, msgspec wants to use CPython private internals like ((PyListObject *)x)->allocated. There is little chance this will ever be supported on PyPy (I say this as the person who has implemented much of the PyPy C-API interoperability). Even if it was supported, it would not be as fast as CPython. In order to properly support PyPy, the _core module (from the 10,000 line _core.c file would need refactoring.

  8. v3ss0n commented on Jun 18, 2023

    @v3ss0n

    Thanks a lot for clarification . for this case then , a lot need to be rewritten for both pypy , and msgspec . What would be the best course of action for developing libraries like this ? On initial development - use HPy ?

  9. mattip commented on Jun 18, 2023

    @mattip

    As @Goldziher stated above

    if someone wanted to pay for this, I might be willing to expand support

    so one path forward would be to put together a proposal to fund a fork or enhancement of msgspec to support PyPy.

  10. Goldziher commented on Jun 18, 2023

    @Goldziher

    As @Goldziher stated above

    if someone wanted to pay for this, I might be willing to expand support

    so one path forward would be to put together a proposal to fund a fork or enhancement of msgspec to support PyPy.

    Wasn't me 😀

  11. mattip commented on Jun 18, 2023

    @mattip

    Sorry, that should have been "as @jcrist stated above ..."

  12. paugier commented on Jun 22, 2023

    @paugier
    * CPython is getting faster, reducing the advantages of PyPy
    

    @jcrist I'm surprised that this argument is used. CPython might get a bit faster in few years but there is a very high probability that PyPy will stay much faster than CPython for most applications.

    It's a bit difficult to build one number to quantify the global efficiency of Python interpreters but CPython 3.11 is something like 1.25 times faster than CPython 3.10 and it seems that CPython 3.12 will be something like 1.3 faster than CPython 3.10 (https://github.com/faster-cpython/benchmarking-public). In contrast, PyPy is more than 4 times faster than CPython (https://speed.pypy.org/). It's not easy to compare these numbers but still PyPy is much faster than CPython.

    Moreover knowing the different technologies used by CPython and PyPy and the constrains in terms of compatibility on CPython, there won't be miracle and unfortunately CPython will stay quite inefficient for a very long time.

  13. v3ss0n commented on Jun 22, 2023

    @v3ss0n
  14. added a commit that references this issue on Feb 19, 2024
  15. pepijndevos commented on Feb 14, 2026

    @pepijndevos

    Could it be reasonable to have a pure python fallback? That would unlock not just pypy but also eg jython, micropython, and cpython installations where compiling C is out of the question.

    In an era of LLMs churning out such a python fallback might not be that hard and there seems to be a demand but of course it is an extra maintenance burden

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions