Fix a possible typo

[cokelaer]

The "def makefile" prototype in gevent/_socket3.py seems wrong with an extra argument called '*'.

This syntax prevents a compilation of the library as a conda recipe.

All tests passed succesfully locally under Python2.7 (running the tests in ./greentest directory).

[jamadden]

Thank you, but that's the correct and required syntax for Python 3. See #685, #601, etc.

[cokelaer]

I was trying to compile gevent for bioconda (a set of conda recipes for biology) and since conda provide gevent with a version 1.0.2 (python2.7) and thought that i would create my own conda recipe for python3.5 and latest version of gevent. Yet, I ran into n syntax error:

File "/anaconda/envs/_build/lib/python2.7/site-packages/gevent-1.1rc4-py2.7-linux-x86_64.egg/gevent/_socket3.py", line 176
def makefile(self, mode="r", buffering=None, *, 

syntaxError: invalid syntax

I'm realising that the underlying python version used is actually python 2.7 , which may explain the syntax error.

thanks for the quick reply.

[jamadden]

Ok, I'm going to go ahead and close this then. (You may find the comments in #478 to be of further help as it's a similar packaging issue.) Please feel free to open other issues if necessary.

[cokelaer]

I've read the different comments from the issues you provided.
I understand that this is correct syntax under Python3 and indeed it does work under PYthon2.x as well.
However, FYI, it may be an issue with conda. After creating a conda recipe for gevent and running this command:

conda build recipes/gevent/ --python=2.7

The package is compiled but because of the error, a status different from 0 is returned and may have side effects (using bioconda, they use a docker to check that builts are passed correctly and in that case gevent does not).

[jamadden]

For downstream distributors with tooling that can't cope with projects that span Python 2 and 3, it's not uncommon for them to modify the source tarball and produce completely separate builds for 2 and 3. That was suggested for the RPM packager; you might consider that. Then, the RPM packager was able to make the tooling work by not precompiling all source files, which would be ideal. (Of course RPM is still Python version specific so it doesn't make much difference.)

Heck, some downstream distributors go so far as to remove libev completely and link to the system-provided libev dynamically. That makes it much harder for upstream to support but they deem it necessary on their platform.

[cokelaer]

thanks.