build
hpy
build | hpy | |
---|---|---|
7 | 20 | |
663 | 1,007 | |
2.0% | 0.6% | |
9.1 | 7.9 | |
8 days ago | 3 days ago | |
Python | Python | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
build
- How can I download a software for my user automatically?
-
Underappreciated Challenges with Python Packaging
If it's pure Python, the only packaging file you need is `pyproject.toml`. You can fill that file with packaging metadata per PEP 518 and PEP 621, including using modern build tooling like flit[1] for the build backend and build[2] for the frontend.
With that, you entire package build (for all distribution types) should be reducible to `python -m build`. Here's an example of a full project doing everything with just `pyproject.toml`[3] (FD: my project).
[1]: https://github.com/pypa/flit
[2]: https://github.com/pypa/build
[3]: https://github.com/pypa/pip-audit
-
"Even with --dry-run pip will execute arbitrary code found in the package's setup.py. In fact, merely asking pip to download a package can execute arbitrary code"
RE the dislike of a "third-party tool", what do you mean by this? All the major tools for packaging in Python are under the PyPA, e.g. - twine - build - hatch
-
'Python: Please stop screwing over Linux distros'
building wheels/sdists to upload or install: build
-
An Interactive Cheat Sheet That Just Gives You The Answer
python3 setup.py sdist bdist_wheel - no need for an sdist when building wheels, also I'd recommend using pypa/build instead.
-
How to Structure a Python AWS Serverless Project
The first step is to turn the internal package into a wheel (a *.whl file). We can use the build tool for this purpose. After installing build with pip we can run it as follows:
-
The future of Python build systems and Gentoo
Shouldn't https://github.com/pypa/build help? I don't think it has enough features yet but I was under the impression that was the distro solution.
hpy
-
RustPython
There is a merge request up to add autogen rust bindings to hpy
https://github.com/hpyproject/hpy/pull/457
-
Ruby 3.2’s YJIT is Production-Ready
Are you referencing https://github.com/hpyproject/hpy?
I do hope it takes off.
- HPy - A better C API for Python
-
Codon: A high-performance Python compiler
The HPy project [0] seems like a promising way out of this.
[0] https://hpyproject.org/
-
New record breaking for Python in TechEmPower
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)
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
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
HPy integration to better support CPython, PyPy and GraalPython
- HPy: A better C API for Python
-
Your Data Fits in RAM
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.
What are some alternatives?
gh-action-pypi-publish - The blessed :octocat: GitHub Action, for publishing your :package: distribution files to PyPI: https://github.com/marketplace/actions/pypi-publish
nogil - Multithreaded Python without the GIL
installer - A low-level library for installing from a Python wheel distribution.
graalpython - A Python 3 implementation built on GraalVM
setuptools - Official project repository for the Setuptools build system
cinder - Cinder is Meta's internal performance-oriented production version of CPython.
pyunifiprotect - Unofficial UniFi Protect Python API and CLI
py2js
awesome-pyproject - An Awesome List of projects using the pyproject.toml Python configuration file.
Pyjion - Pyjion - A JIT for Python based upon CoreCLR
pipx - Install and Run Python Applications in Isolated Environments
pgcopy - fast data loading with binary copy