gevent is a coroutine-based Python networking library.
- Fast event loop based on libev.
- Lightweight execution units based on greenlet.
- Familiar API that re-uses concepts from the Python standard library.
- Cooperative sockets with SSL support.
- DNS queries performed through c-ares or a threadpool.
- Ability to use standard library and 3rd party modules written for standard blocking sockets
gevent is inspired by eventlet but features more consistent API, simpler implementation and better performance. Read why others use gevent and check out the list of the open source projects based on gevent.
gevent is licensed under the MIT license.
See what's new in the latest major release.
Check out the detailed changelog for this version.
gevent runs on Python >= 2.7, Python >= 3.4, or PyPy >= 5.5 (including PyPy2 and PyPy3) (Note: PyPy is not supported in Windows). On all platforms, installing setuptools is required (this is done automatically if working in a virtual environment).
You can use pip to install gevent:
pip install gevent
You need Pip 8.0 or later to install the binary wheels.
To install the latest development version:
pip install setuptools 'cython>=0.25' git+git://github.com/gevent/gevent.git#egg=gevent
To hack on gevent (using a virtualenv):
$ git clone https://github.com/gevent/gevent.git $ cd gevent $ virtualenv env $ source env/bin/activate (env) $ pip install -r dev-requirements.txt
You must have Cython, GNU Make, a C compiler, and the Python development headers installed to build a checkout. Installing CFFI on CPython (it's standard on PyPy) allows building the CFFI backend for testing, and tox is the command used to test multiple versions of Python.
BSD based systems like FreeBSD and OpenBSD often have BSD Make on
the PATH as the default
make command, but building gevent from a
source checkout (not a source tarball distributed on PyPI) requires
GNU Make. GNU Make is often called
gmake. If you experience
Makefile-related problems building gevent from source on one of
these platforms, you can set the
MAKE environment variable to
the executable that invokes GNU Make. For example:
$ MAKE=gmake python ./setup.py install
There are a few different ways to run the tests. To simply run the tests on one version of Python during development, try this:
python setup.py develop cd src/greentest PYTHONPATH=.. python testrunner.py --config known_failures.py
Before submitting a pull request, it's a good idea to run the tests across all supported versions of Python, and to check the code quality using prospector. This is what is done on Travis CI. Locally it can be done using tox:
pip install tox tox
The testrunner accepts a
--coverage argument to enable code
coverage metrics through the coverage.py package. That would go
something like this:
cd src/greentest PYTHONPATH=.. python testrunner.py --config known_failures.py --coverage coverage combine coverage html -i <open htmlcov/index.html>
Builds on Travis CI automatically submit updates to coveralls.io to monitor test coverage.
Likewise, builds on Travis CI will automatically submit updates to landscape.io to monitor code health (adherence to PEP8, absence of common code smells, etc).
On Debian, you will probably need
installed to run all the tests.
A test suite is run for every push and pull request submitted. Travis CI is used to test on Linux, and AppVeyor runs the builds on Windows.