pygit2
xni
Our great sponsors
| pygit2 | xni | |
|---|---|---|
| 1 | 1 | |
| 1,575 | 7 | |
| 0.8% | - | |
| 9.1 | 0.0 | |
| 8 days ago | almost 10 years ago | |
| Python | Java | |
| GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
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.
pygit2
-
Hello, HPy
It still is, and Cython is great for accelerating critical Python code.
A C extension is far preferable when you want to code in C, either to write a new data type[1], or write a Python frontend to a C library[2] that is too complex to be well supported by simple FFI.
I think people use Cython more internally when they value the maintainability of "mostly Python" over the fact that it's slower than what native C would get them.
[1]: https://github.com/tobgu/pyrsistent
[2]: https://github.com/libgit2/pygit2
xni
-
Hello, HPy
We have this same problem in Ruby - implementing the Ruby C extension API if you aren't exactly the same as the reference Ruby implementation is extremely challenging. I think Charlie Nutter proposed something like this for Ruby in the past https://github.com/headius/xni.
What are some alternatives?
libgit2 - A cross-platform, linkable library implementation of Git that you can use in your application.
Pyrsistent - Persistent/Immutable/Functional data structures for Python
Guitar - Git GUI Client
tig - Text-mode interface for git
gti - a git launcher :-)
RustPython - A Python Interpreter written in Rust