HPy: a better API for Python (by hpyproject)

Hpy Alternatives

Similar projects and alternatives to hpy

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better hpy alternative or higher similarity.

hpy reviews and mentions

Posts with mentions or reviews of hpy. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-01-17.
  • Ruby 3.2’s YJIT is Production-Ready
    8 projects | news.ycombinator.com | 17 Jan 2023
    Are you referencing https://github.com/hpyproject/hpy?

    I do hope it takes off.

  • Codon: A high-performance Python compiler
    12 projects | news.ycombinator.com | 8 Dec 2022
    The HPy project [0] seems like a promising way out of this.

    [0] https://hpyproject.org/

  • New record breaking for Python in TechEmPower
    2 projects | reddit.com/r/Python | 8 Dec 2022
    socketify.py breaks the record for Python no other Python WebFramework/Server as able to reach 6.2 mi requests per second before in TechEmPower Benchmarks, this puts Python at the same level of performance that Golang, Rust and C++ for web development, in fact Golang got 5.2 mi req/s in this same round. Almost every server or web framework tries to use JIT to boost the performance, but only socketify.py deliveries this level of performance, and even without JIT socketify.py is twice as fast any other web framework/server in active development, and still can be much more optimized using HPy (https://hpyproject.org/). Python will get even faster and faster in future!
  • Is it time to leave Python behind? (My personal rant)
    4 projects | reddit.com/r/Python | 27 Nov 2022
    I think Propose a better messaging for Python is the option and a lot of languages will learn it from Rust, because rust erros are the best described errors I see in my life lol. Cargo is amazing and I think we will need a better poetry/pip for sure, HPy project will modernize extensions and packages 📦 too https://hpyproject.org/
  • A Look on Python Web Performance at the end of 2022
    10 projects | dev.to | 14 Nov 2022
    It also show that PyPy3 will not magically boost your performance, you need to integrate in a manner that PyPy3 can optimize and delivery CPU performance, with a more complex example maybe it can help more. But why socketify is so much faster using PyPy3? The answer is CFFI, socketify did not use Cython for integration and cannot delivery the full performance on Python3, this will be solved with HPy.
  • socketify.py - Bringing WebSockets, Http/Https High Peformance servers for PyPy3 and Python3
    5 projects | reddit.com/r/Python | 8 Nov 2022
    HPy integration to better support CPython, PyPy and GraalPython
  • Your Data Fits in RAM
    4 projects | news.ycombinator.com | 2 Aug 2022
    Absolutely everything in CPython is a PyObject, and that can’t be changed without breaking the C API. A PyObject contains (among other things) a type pointer, a reference count, and a data field; none of these things can be changed without (again) breaking the C API.

    There have definitely been attempts to modernize; the HPy project (https://hpyproject.org/), for instance, moves towards a handle-oriented API that keeps implementation details private and thus enables certain optimizations.

  • Python 3.11 is up to 10-60% faster than Python 3.10
    2 projects | reddit.com/r/programming | 6 Jul 2022
    NumPy is a sore point (works, but slow) and the missing spark to ignite PyPy adoption for a subset of users. The current hope seems to be HPy. If PyPy acquires good NumPy performance, a lot of people would migrate. Also of note is that conda-forge builds hundreds of packages for PyPy already (I think they started doing that in 2020).
  • The future of Python build systems and Gentoo
    8 projects | news.ycombinator.com | 10 Dec 2021
    I've battled with Python's packaging systems for more than a decade. Every couple of years some new thing comes along promising to fix package management, but it always fails spectacularly on some important, mainstream package or use case. I suspect a lot of this complexity comes down to the significant degree in which the Python ecosystem depends on C: not only do we need to package Python programs but C programs as well, and some people think we should ship C source code and build on the target machine and others think we should ship pre-built C binaries and dynamically link against them on the target machine thus Python supports both mechanisms; however, both are perilous in the general case.

    And interestingly, Python depends so hard on C because CPython is very slow, and CPython is very slow because the C-extension API is virtually the whole of the CPython interpreter (many interesting optimizations to the interpreter would break compatibility in the ecosystem). So it certainly feels like all of Python's major problems come down to this decision to lean hard on C and specifically to make so much of the interpreter available for the C-extensions.

    The way out as far as I can tell is to define some narrower API surface (e.g., https://hpyproject.org), get the ecosystem to consolidate around that, deprecate the old API surface, and then make the requisite breaking optimizations such that the ecosystem can feasibly do more in native Python. This requires leadership; however, and this has not historically seemed to be Python's strong suite--the Python maintainers seem unable to drive out big, necessary changes like this (which is certainly not to say that leadership is easy, particularly when Python is so established in many respects).

    Personally, I've come to use Go for 99% of my Python use cases and it's been great. There are dramatically fewer C bindings, so the build/packaging tooling and performance are orders of magnitude better than in Python. Static typing works well out of the box, real static binaries are not only feasible but trivial (as opposed to Python where you try to build a zip file with your dependencies and the result is hundreds of megabytes and it's still missing the runtime, std libs, and various .so files). Further still, builds, tests, and every kind of tooling are far faster than with Python, and far simpler to install and manage. Unless you're doing data science, I don't think you'll regret the transition.

  • A viable solution for Python concurrency
    6 projects | news.ycombinator.com | 15 Oct 2021
    Now could be a good time to make this change, in coordination with HPy: https://github.com/hpyproject/hpy

    I agree though — it’s tempting to keep extending and stretching the language to be something it was never designed for; but at some point it’s been stretched so far it loses the properties that made it attractive to start with. I like Python, but some of the things people are using it for now, they should really consider another language instead, and write a Python wrapper on top of that if they must use it from Python.

  • A note from our sponsor - Sonar
    www.sonarsource.com | 7 Feb 2023
    Sonar helps you commit clean code every time. With over 225 unique rules to find Python bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work. Learn more →


Basic hpy repo stats
7 days ago
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives