Coroutine-based concurrency library for Python

Overview
Issues
  • python3

    python3

    Would be cool to have python3 support, ideally as single source.

    Here's an old python3 fork: http://bitbucket.org/jjonte/gevent

    Reported by Denis.Bilenko.


    earlier comments

    Denis.Bilenko said, at 2011-01-28T05:36:07.000Z:

    There's some work going on at https://bitbucket.org/Edmund_Ogban/gevent-py3k

    [email protected] said, at 2011-03-20T18:40:50.000Z:

    Exception handling is a problem here. With Python2.5 there is only except Exception, e, whereas Python3.x requires except Exception as e.

    Making this single source supporting 2.5 and higher is therefore quite difficult. Or is there some future that can be used to simulate the new syntax included with the language since 2.6?

    Otherwise I would say: drop support for Python 2.5 with the next release version, and make that one compatible with 2.6 .. 3.2.

    anacrolix said, at 2011-09-13T00:03:14.000Z:

    I'm keen to try gevent, but I sailed for Python3 over a year ago.

    anacrolix said, at 2011-09-20T00:23:26.000Z:

    Denis can you report on the status of Python3 support for gevent?

    Denis.Bilenko said, at 2011-12-20T18:14:35.000Z:

    Issue 89 has been merged into this issue.

    luchenue said, at 2011-12-23T09:14:52.000Z:

    Any news ?

    anacrolix said, at 2011-12-23T11:09:10.000Z:

    From what I've observed, I don't think Denis wants to break support for Python 2 yet, and so won't accept patches that don't support both 2 *and* 3, which is a complex obstacle.

    k.cherkasoff said, at 2011-12-23T11:42:53.000Z:

    Is there any up to date forks for python 3.x ?

    whitelynx said, at 2012-02-01T07:13:18.000Z:

    I think the general approach for maintaining anything that's supposed to work on 2.5 - 3.x is to use the 2to3 tool to automatically generate a python3 version from the python2 source. The exception handling issue mentioned by carsten above (comment 2) is treated by the 'except' fixer in 2to3. (http://docs.python.org/library/2to3.html?highlight=except#2to3fixer-except) Since fixers can be run individually, it shouldn't be too difficult to put together a 2to3 command line that would be able to translate gevent with a minimum amount of breakage, and then just manually clean up the results. I do wish there was a 3to2 or similar that would translate some of the python3-style idioms to something compatible with 2.5, as with the 'except _ as _' syntax.

    amcnabb8 said, at 2012-02-09T19:14:00.000Z:

    The six library makes it very easy to support both Python 2 (>=2.6) and Python 3 without needing 2to3. With a couple of workarounds, Michael Foord has shown that it's entirely possible to support Python 2.4 without 2to3. But really, it's not as hard as it sounds to support both Python 2 and 3, and there are two reasonable approaches.

    PyVer: python3 
    opened by denik 98
  • PyPy support

    PyPy support

    As per the discussions on #pypy @ irc.freenode.org, it's been reported that pypycore runs successfully, with minor as of yet unfixed bugs, on PyPy 2.0 dev and is able to outperform gevent on CPython in some benchmarks by a factor of 2.

    So in general, could we hope for a future direction of the adaptations in pypycore becoming an integral part of gevent? Something comparable to how gevent-zeromq has become part of pyzmq in recent versions (http://zeromq.github.com/pyzmq/api/zmq.green.html#module-zmq.green).

    This would, in the future, give us an awesome stack of gevent and ZeroMQ running on PyPy with the currently under development but functional JIT compilation support for continulet based stacks (which include greenlet and stackless), easily on par in its potential with the success of Node.js.

    Interp: pypy 
    opened by erikkaplun 69
  • gevent breaks try-finally semantics where greenlet doesn't

    gevent breaks try-finally semantics where greenlet doesn't

    Greenlets in greenlet always get their finally block invoked for example when a KeyboardInterrupt occurs. To reproduce:

    import time, greenlet
    def bar():
        try: greenlet.getcurrent().parent.switch()
        finally: print "CLEANUP BAR"
    def foo():
        try: time.sleep(1.0)
        finally: print "CLEANUP FOO"
    b1 = greenlet.greenlet(bar)
    b1.switch()
    b2 = greenlet.greenlet(bar)
    b2.switch()
    greenlet.greenlet(foo).switch()
    

    ...2 x CLEANUP BAR + 1 x CLEANUP FOO gets printed when Ctrl-C is pressed during that time.sleep(1.0) call.

    However, when using gevent (unless time.sleep is used, for obvious reasons), no cleanup code gets invoked whatsoever when Ctrl-C is pressed:

    from gevent import spawn, sleep
    from gevent.event import Event
    def bar():
        try: Event().wait()  # just block and switch back to main
        finally: print "CLEANUP BAR"
    def foo():
        try: sleep(1.0)
        finally: print "CLEANUP FOO"  # this does get printed for obvious reasons if time.sleep is used instead
    gevent.joinall([spawn(bar), spawn(bar), spawn(foo)])
    

    ...neither CLEANUP FOO nor CLEANUP BAR gets printed.

    This is both weird, because greenlet already handles this automatically, as well as inconsistent with standard Python semantics, which I suppose should always be sticked to. Violating fundamental semantic guarantees of the language will eventually cause confusion and problems, or at least inconvenience, such as having to manually keep track of all spawned greenlets and to kill them in a global finally cleanup block, or in a signal handler—i.e. stuff that should be expected from gevent.

    (I've run the above code on OS X 10.7 and 64bit Python 2.7)

    P.S. Also, an except KeyboardInterrupt block never gets invoked either.

    opened by erikkaplun 28
  • Gevent.spawn, ctypes callbacks and thread safety

    Gevent.spawn, ctypes callbacks and thread safety

    When using ctypes callbacks the documentation is as follows:

    https://docs.python.org/3/library/ctypes.html#callback-functions

    Also, note that if the callback function is called in a thread created outside of Python’s control (e.g. by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation. This behavior is correct for most purposes, but it means that values stored with threading.local will not survive across different callbacks, even when those calls are made from the same C thread.

    I need to schedule the execution of the code inside the callback. The execution should happen in the Hub with which the callback has been created in the first place. The "dummy thread" however, is an actual physical pseudo-Python thread, even if Gevent monkey-patched the threading module beforehand.

    When registering a callback I can capture the hub from the current gevent thread.

    Is there a safe way to inject a Greenlet into a hub i.e. something like gevent.spawn() whilst passing the Hub to the spawn from a different physical thread the same way as loop.call_soon_threadsafe works in asyncio? (https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.call_soon_threadsafe)?

    Type: Question 
    opened by arcivanov 27
  • EOF occurred in violation of protocol

    EOF occurred in violation of protocol

    I am trying to run a socket server with ssl support. For this purpose I am usung flask-socketio which uses gevent behind. I think flask-socketio has nothing to do with ssl options, it is just passing to ssl configurations to gevent init.

    Socket server with ssl support was possible, but after re-installing all the pip packages, I started to get the following error.

    Traceback (most recent call last):
      File "/usr/local/lib/python2.7/dist-packages/gevent/greenlet.py", line 327, in run
        result = self._run(*self.args, **self.kwargs)
      File "/usr/local/lib/python2.7/dist-packages/gevent/server.py", line 102, in wrap_socket_and_handle
        ssl_socket = self.wrap_socket(client_socket, **self.ssl_args)
      File "/usr/local/lib/python2.7/dist-packages/gevent/_ssl2.py", line 410, in wrap_socket
        ciphers=ciphers)
      File "/usr/local/lib/python2.7/dist-packages/gevent/_ssl2.py", line 93, in __init__
        self.do_handshake()
      File "/usr/local/lib/python2.7/dist-packages/gevent/_ssl2.py", line 310, in do_handshake
        return self._sslobj.do_handshake()
    SSLError: [Errno 8] _ssl.c:510: EOF occurred in violation of protocol
    <Greenlet at 0x7fbc02c4a9b0: <bound method WSGIServer.wrap_socket_and_handle of <WSGIServer at 0x7fbc03b9b110 fileno=9 address=0.0.0.0:5000>>(<socket at 0x7fbc02bf7590 fileno=76 sock=10.122.97, ('41.234.232.59', 40471))> failed with SSLError
    

    is there any solution?

    Type: Bug PyVer: python3 
    opened by muatik 24
  • ssl broken on Debian (and derivatives), as of python 2.7.8-12

    ssl broken on Debian (and derivatives), as of python 2.7.8-12

    In v2.7.8-12 of the Debian python suit, which was released 3 days ago, they added a patch, which, according to the changelog, "Allow building and testing without SSLv3 support"

    In fact it removes many of the SSLv3-related constants, including ROTOCOL_SSLv3, which make gevent fail with a message similar to this:

      File "<whatever>/h/local/lib/python2.7/site-packages/gevent/ssl.py", line 386, in <module>
        def get_server_certificate(addr, ssl_version=PROTOCOL_SSLv3, ca_certs=None):
    NameError: name 'PROTOCOL_SSLv3' is not defined
    

    One could argue that it's not nice for a distribution to haphazardly remove constants that are still there in the upstream version, but these things happen, so... maybe gevent could do something about this? (Like, maybe, move to 'PROTOCOL_SSLv23' instead?)

    opened by csillag 21
  • Removal of select.poll() breaks subprocess module.

    Removal of select.poll() breaks subprocess module.

    I haven't encountered this directly, but have now had a couple of New Relic Python agent users raise the problem with us.

    The problem is that in the Python subprocess module it has:

    import select
    _has_poll = hasattr(select, 'poll')
    

    Thus _has_poll will only be true if poll() exists in the select module.

    Later it has:

                if _has_poll:
                    stdout, stderr = self._communicate_with_poll(input)
                else:
                    stdout, stderr = self._communicate_with_select(input)
    

    and then in _communicate_with_poll() it has:

    poller = select.poll()
    

    The problem is that in gevent monkey patching it will remove the poll() function from the select module.

    def patch_select(aggressive=True):
        """Replace :func:`select.select` with :func:`gevent.select.select`.
    
        If aggressive is true (the default), also remove other blocking functions the :mod:`select`.
        """
        patch_module('select')
        if aggressive:
            select = __import__('select')
            # since these are blocking we're removing them here. This makes some other
            # modules (e.g. asyncore)  non-blocking, as they use select that we provide
            # when none of these are available.
            remove_item(select, 'poll')
            remove_item(select, 'epoll')
            remove_item(select, 'kqueue')
            remove_item(select, 'kevent')
    

    The end result is that if the subprocess module had been imported prior to gevent doing any monkey patching, then gevent is breaking the subprocess module as it has cached that the poll() function existed.

    You therefore get:

    File "/usr/lib/python2.7/subprocess.py", line 799, in communicate return self._communicate(input)
    File "/usr/lib/python2.7/subprocess.py", line 1401, in _communicate stdout, stderr = self._communicate_with_poll(input)
    File "/usr/lib/python2.7/subprocess.py", line 1431, in _communicate_with_poll poller = select.poll()
    AttributeError: 'module' object has no attribute 'poll'
    

    If gevent is going to remove the poll() function, it should perhaps update the subprocess module and set _have_poll to False to avoid the problem.

    One could argue gevent shouldn't need to consider that other modules have cached stuff from the select module, but since subprocess is part of the standard library, may be prudent to consider addressing the problem.

    opened by GrahamDumpleton 21
  • Cython dependency has changed in some way?

    Cython dependency has changed in some way?

    I don't know if this is a gevent issue or not. On AppVeyor (a Windows CI service), I used to be able to install coverage.py and its gevent dependency just fine (ignore 2.6 for the moment): https://ci.appveyor.com/project/nedbat/coveragepy/build/default-280

    Then recently (in the last week), the builds started failing for everything, because Cython wasn't available: https://ci.appveyor.com/project/nedbat/coveragepy/build/default-285

    It looks like gevent requires Cython at install time, but only declares that in certain circumstances. I don't see how that has changed recently, but something has.

    Can you help?

    opened by nedbat 19
  • Failed to build gevent 21.1.2

    Failed to build gevent 21.1.2

    • gevent version: 21.1.2 installed through pip 21.0
    • Python version: Python 3.9.1 built from source from python.org through Macports 2.6.4
    • Operating System: MacOS 10.11.6

    Description:

    Error Message (Complete build output in build.txt) :

     /usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -I/opt/local/include -I/opt/local/include -DLIBEV_EMBED=1 -DEV_COMMON= -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -DEV_USE_REALTIME=1 -DEV_USE_MONOTONIC=1 -DEV_USE_FLOOR=1 -Isrc/gevent/libev -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -I/private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/deps -I/private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/src/gevent/libev -I/private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/deps/libev -Isrc/gevent -Isrc/gevent/libev -Isrc/gevent/resolver -I. -I/Users/yves/.virtualenvs/passages/include -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c src/gevent/libev/corecext.c -o build/temp.macosx-10.11-x86_64-3.9/src/gevent/libev/corecext.o -Wno-unreachable-code -Wno-deprecated-declarations -Wno-incompatible-sysroot -Wno-tautological-compare -Wno-implicit-function-declaration -Wno-unused-value -Wno-macro-redefined
      In file included from src/gevent/libev/corecext.c:872:
      In file included from src/gevent/libev/libev.h:9:
      /private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/deps/libev/ev.c:4105:34: error: use of undeclared identifier 'have_monotonic'
                  if (ecb_expect_true (have_monotonic))
                                       ^
      1 error generated.
      error: command '/usr/bin/clang' failed with exit code 1
      ----------------------------------------
      ERROR: Failed building wheel for gevent
    Failed to build gevent
    ERROR: Could not build wheels for gevent which use PEP 517 and cannot be installed directly
    [build.txt](https://github.com/gevent/gevent/files/5863150/build.txt)
    

    Thanks !

    Platform: POSIX Platform: Unsupported environment 
    opened by yesyves 18
  •  osx 10.11.1 , could not create  '/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet': Operation not permitted

    osx 10.11.1 , could not create '/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet': Operation not permitted

    osx 10.11.1 , install gevent , i get an error ,

    sudo  -H pip install greenlet
    
     could not create  '/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet': Operation not permitted  
    

    i am is root , but ,why can't Operation not permitted ?

    here is the detail message:

    HackedBy007:~ weirdbird007$ sudo  -H pip install greenlet
    Password:
    Collecting greenlet
      Using cached greenlet-0.4.9.tar.gz
    Installing collected packages: greenlet
      Running setup.py install for greenlet
        Complete output from command /usr/bin/python -c "import setuptools, tokenize;__file__='/private/tmp/pip-build-6KNYrr/greenlet/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-brHEyp-record/install-record.txt --single-version-externally-managed --compile:
        running install
        running build
        running build_ext
        building 'greenlet' extension
        creating build
        creating build/temp.macosx-10.11-intel-2.7
        cc -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c greenlet.c -o build/temp.macosx-10.11-intel-2.7/greenlet.o
        creating build/lib.macosx-10.11-intel-2.7
        cc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -Wl,-F. build/temp.macosx-10.11-intel-2.7/greenlet.o -o build/lib.macosx-10.11-intel-2.7/greenlet.so
        running install_lib
        copying build/lib.macosx-10.11-intel-2.7/greenlet.so -> /Library/Python/2.7/site-packages
        running install_headers
        creating /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet
        error: could not create '/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet': Operation not permitted
    
        ----------------------------------------
    
    Status: not gevent 
    opened by changheluor007 18
  • why does my gevent run slowly than the normal program ?

    why does my gevent run slowly than the normal program ?

    Python Version : 3.7.3 IDE : pycharm problems : I make a speed testing. I am trying to read the local file whihc are more then 2000 , it took for 6.5 seconds when i use the gevent moulde, another took for 2.8 seconds when normally i used 'for in'. I want to know why does not gevent raise efficiency for I/O.

    Type: Question 
    opened by allwell997 17
  • gevent.select.select still mark socket readable after all data is read on windows

    gevent.select.select still mark socket readable after all data is read on windows

    • gevent version: 21.12 from pip
    • Python version: cPython 3.7.6 downloaded from python.org
    • Operating System: windows 7 x64

    Description:

    It seems that there is a bug in gevent.select.select on windows. After a socket read all data from its peer, and run select.select again against it, it is still returned as readable, but in fact there is no data in buffer, and a following .recv() will lead to blocking.

    test code:

    import gevent
    import gevent.monkey
    gevent.monkey.patch_all()
    
    import gevent.socket
    import gevent.select
    
    server = gevent.socket.socket()
    server.bind(('127.0.0.1', 12345))
    server.listen(5)
    
    
    def socket_proc(socket):
        data = b''
        while True:
            r, w, x = gevent.select.select([socket, ], [], [socket, ], timeout=0.1)
            if r:
                data += socket.recv(1024)
            else:
                if data:
                    socket.send((u'%s\n' % len(data)).encode('utf-8'))
                    data = b''
    
    
    def listen_proc(server):
        while True:
            socket, _ = server.accept()
            gevent.spawn(socket_proc, socket)
    
    
    print('start..')
    listen_proc(server)
    

    One may use any tcp client, such as netcat, to send a short piece of data to the listening port, and will not receive any reply. Debugging shows that when the program calls the select() for the 2nd time, it still return the socket object in r, since there is no pending data in it, the next call to socket.recv() blocks forever.

    It seems this is a windows specific bug, as I've test it on linux and works without problem

    I've done the following tests (all on widows, all python version are downloaded from python.org, gevent installed by pip)

    • python 2.7.11+ gevent 1.2.2: works
    • python 2.7.11+ gevent 1.3.0: buggy
    • python 2.7.11+ gevent 1.4.0: buggy
    • python 2.7.11+ gevent 1.5.0: buggy
    • python 2.7.11+ gevent 21.12: buggy
    • python 3.7.6+ gevent 21.12: buggy

    So I guess this is something related to libuv

    opened by adamhj 1
  • Publish wheel for M1 Mac (arm64)

    Publish wheel for M1 Mac (arm64)

    • gevent version: 21.12.0
    • Python version: 3.9.12
    • Operating System: MacBook Air (M1, 2020) Darwin Kernel Version 21.4.0: arm64

    Description:

    Installing the latest version of gevent on an M1 Mac requires building from source:

    Building wheels for collected packages: gevent
      Building wheel for gevent (PEP 517) ... done
      Created wheel for gevent: filename=gevent-21.12.0-cp39-cp39-macosx_12_0_arm64.whl size=1732438 sha256=717895d5c98c05665286ab0284629d9f1642f947b710c1ad1b3e3115d589f470
    

    This takes a long time which slows down project setup. Publishing a wheel for arm64 would greatly speed this up.

    What I've run:

    pip install gevent

    opened by tyates-indeed 0
  • AttributeError: 'gevent.libev.corecext.io' object has no attribute 'active'

    AttributeError: 'gevent.libev.corecext.io' object has no attribute 'active'

    • gevent version: 21.12.0, installed via pip 22.0.2 from /usr/lib/python3/dist-packages/pip (python 3.10)
    • Python version: 3.10.4, installed via Ubuntu 22.04
    • Operating System: Ubuntu 22.04

    Description:

    Hi,

    I updated my system from Ubuntu 21.10 to 22.04 (and therefore from Python 3.9 to 3.10) and now our uwsgi application throws the following traceback very often:

    
    The above exception was the direct cause of the following exception:
    
    Traceback (most recent call last):
      File "src/gevent/greenlet.py", line 906, in gevent._gevent_cgreenlet.Greenlet.run
    SystemError: <built-in function uwsgi_gevent_request> returned a result with an exception set
    2022-05-05T09:31:14Z <Greenlet at 0x7f8a5a4a8a60: uwsgi_gevent_request(140232338205640)> failed with SystemError
    
    AttributeError: 'gevent.libev.corecext.io' object has no attribute 'active'
    
    The above exception was the direct cause of the following exception:
    
    Traceback (most recent call last):
      File "src/gevent/greenlet.py", line 831, in gevent._gevent_cgreenlet.Greenlet.join
      File "src/gevent/greenlet.py", line 857, in gevent._gevent_cgreenlet.Greenlet.join
      File "src/gevent/greenlet.py", line 846, in gevent._gevent_cgreenlet.Greenlet.join
      File "src/gevent/_greenlet_primitives.py", line 61, in gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop.switch
      File "src/gevent/_greenlet_primitives.py", line 61, in gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop.switch
      File "src/gevent/_greenlet_primitives.py", line 65, in gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop.switch
      File "src/gevent/_gevent_c_greenlet_primitives.pxd", line 35, in gevent._gevent_c_greenlet_primitives._greenlet_switch
      File "src/gevent/greenlet.py", line 906, in gevent._gevent_cgreenlet.Greenlet.run
    SystemError: <built-in function uwsgi_gevent_request> returned a result with an exception set
    
    

    I am not really sure if this is a gevent problem, but hopefully someone can give me hint where to look at.

    If any information is missing to help, please let me know.

    Best regards, Thomas

    opened by othiman 0
  • [aarch64] CORRECT VERSIONS, however RuntimeWarning: greenlet.greenlet size changed

    [aarch64] CORRECT VERSIONS, however RuntimeWarning: greenlet.greenlet size changed

    • gevent version: 21.12.0 - once installed from PyPi, once built from the master branch
    • Python version:3.7.6 - shipped with OS (see below)
    • Operating System: Alchemy 2021.04, aarch64 architecture

    Description:

    Recently, I wanted to get zerorpc running, that is based on greenlet and gevent. Importing zerorpc, leads to

    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    

    Only importing gevent, leads to these Warnings as well:

    >>> import gevent
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject
      return f(*args, **kwds)
    

    What I've run:

    Gevent version is 21.12.0, greenlet version is 1.1.2. The python version is the one the Linux OS is shipped with. I am well aware that this issue is already fixed. However, the versions we use are way higher. Running this on on an Ubuntu 20.04, with x86_64 archictecture with (apparently) the same package versions, everything runs smoothly...

    We also tried the following - yielding the same error:

    • pulling from master branch (gevent and greenlet)
    • using the most recent tags of the respective repos
    • installing gevent==20.9.0 and greenlet==0.4.17

    Thanks for your help!

    opened by tokr-bit 0
  • Closing a waiting selector from another greenlet results in a TypeError

    Closing a waiting selector from another greenlet results in a TypeError

      File "/home/<snip>/lib/python3.10/site-packages/gevent/selectors.py", line 208, in select
        for fd, event in iteritems(self._accumulated_events):
    TypeError: descriptor 'items' for 'dict' objects doesn't apply to a 'NoneType' object
    

    The issue is as follows:

    selector.close: https://github.com/gevent/gevent/blob/5858d226045f701deb8e4b49c03db4cab63053d6/src/gevent/selectors.py#L241

    selector.select: https://github.com/gevent/gevent/blob/5858d226045f701deb8e4b49c03db4cab63053d6/src/gevent/selectors.py#L201-L208

    opened by arcivanov 3
  • Improve format run info

    Improve format run info

    This adds include_ready parameter to format_run_info() etc so that the dump can exclude greenlets that are ready. Also, changed the output from labeling such greenlets as ; finished to labeling them ; ready (finished) since the code's terminology for a finished greenlet is that it is "ready". Also, the dummy function _ready() is renamed _return_false() to better self-document its purpose.

    opened by aathan 2
Releases(1.2.2)
A utility for mocking out the Python Requests library.

Responses A utility library for mocking out the requests Python library. Note Responses requires Python 2.7 or newer, and requests >= 2.0 Installing p

Sentry 3.6k May 17, 2022
A mocking library for requests

httmock A mocking library for requests for Python 2.7 and 3.4+. Installation pip install httmock Or, if you are a Gentoo user: emerge dev-python/httm

Patryk Zawadzki 444 May 5, 2022
The successor to nose, based on unittest2

Welcome to nose2 nose2 is the successor to nose. It's unittest with plugins. nose2 is a new project and does not support all of the features of nose.

null 707 May 13, 2022
Meinheld is a high performance asynchronous WSGI Web Server (based on picoev)

What's this This is a high performance python wsgi web server. And Meinheld is a WSGI compliant web server. (PEP333 and PEP3333 supported) You can als

Yutaka Matsubara 1.4k Apr 28, 2022
Green is a clean, colorful, fast python test runner.

Green -- A clean, colorful, fast python test runner. Features Clean - Low redundancy in output. Result statistics for each test is vertically aligned.

Nathan Stocks 735 May 13, 2022
Scalable user load testing tool written in Python

Locust Locust is an easy to use, scriptable and scalable performance testing tool. You define the behaviour of your users in regular Python code, inst

Locust.io 18.9k May 17, 2022
A cross-platform GUI automation Python module for human beings. Used to programmatically control the mouse & keyboard.

PyAutoGUI PyAutoGUI is a cross-platform GUI automation Python module for human beings. Used to programmatically control the mouse & keyboard. pip inst

Al Sweigart 6.6k May 16, 2022
splinter - python test framework for web applications

splinter - python tool for testing web applications splinter is an open source tool for testing web applications using Python. It lets you automate br

Cobra Team 2.5k May 13, 2022
Let your Python tests travel through time

FreezeGun: Let your Python tests travel through time FreezeGun is a library that allows your Python tests to travel through time by mocking the dateti

Steve Pulec 3.3k May 15, 2022
HTTP client mocking tool for Python - inspired by Fakeweb for Ruby

HTTPretty 1.0.5 HTTP Client mocking tool for Python created by Gabriel Falcão . It provides a full fake TCP socket module. Inspired by FakeWeb Github

Gabriel Falcão 2k May 11, 2022
A test fixtures replacement for Python

factory_boy factory_boy is a fixtures replacement based on thoughtbot's factory_bot. As a fixtures replacement tool, it aims to replace static, hard t

FactoryBoy project 2.8k May 16, 2022
Mixer -- Is a fixtures replacement. Supported Django, Flask, SqlAlchemy and custom python objects.

The Mixer is a helper to generate instances of Django or SQLAlchemy models. It's useful for testing and fixture replacement. Fast and convenient test-

Kirill Klenov 822 May 20, 2022
Faker is a Python package that generates fake data for you.

Faker is a Python package that generates fake data for you. Whether you need to bootstrap your database, create good-looking XML documents, fill-in yo

Daniele Faraglia 14.2k May 19, 2022
Mimesis is a high-performance fake data generator for Python, which provides data for a variety of purposes in a variety of languages.

Mimesis - Fake Data Generator Description Mimesis is a high-performance fake data generator for Python, which provides data for a variety of purposes

Isaak Uchakaev 3.6k May 22, 2022
Radically simplified static file serving for Python web apps

WhiteNoise Radically simplified static file serving for Python web apps With a couple of lines of config WhiteNoise allows your web app to serve its o

Dave Evans 2k May 18, 2022
livereload server in python (MAINTAINERS NEEDED)

LiveReload Reload webpages on changes, without hitting refresh in your browser. Installation python-livereload is for web developers who know Python,

Hsiaoming Yang 964 May 8, 2022
A screamingly fast Python 2/3 WSGI server written in C.

bjoern: Fast And Ultra-Lightweight HTTP/1.1 WSGI Server A screamingly fast, ultra-lightweight WSGI server for CPython 2 and CPython 3, written in C us

Jonas Haag 2.8k May 20, 2022
Waitress - A WSGI server for Python 2 and 3

Waitress Waitress is a production-quality pure-Python WSGI server with very acceptable performance. It has no dependencies except ones which live in t

Pylons Project 1.1k May 9, 2022
Python HTTP Server

Python HTTP Server Preview Languange and Code Editor: How to run? Download the zip first. Open the http.py and wait 1-2 seconds. You will see __pycach

SonLyte 16 Oct 21, 2021