Bjoern: Compatibilidad con Python 3 (PEP 3333)

Vine a publicar lo mismo. Estoy dispuesto pero tengo literalmente cero experiencia con las extensiones de C. Si puedo ser de alguna ayuda, hágamelo saber. Si puede señalarme una herramienta decente o un documento que describa la portabilidad de las extensiones de 2 a 3, lo analizaré y probaré suerte.

No debería ser demasiado difícil ya que no hay mucho que necesita ser portado.

Como PyString_foo se ha ido en Py3, necesitamos usar una macro para el tipo de cadena nativa (clave/valores de dictado WSGI).

Consulte también http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ para obtener ayuda general sobre la migración de Py2 a Py3.

Si tiene alguna pregunta, no dude en escribir un correo electrónico :)

Para que conste, aquí está la diferencia entre PEP 333 y PEP 3333: http://paste.pocoo.org/show/320496/

Disculpas, pero no voy a ser capaz de lograr esto por mi cuenta. Espero que algo aquí pueda ser de ayuda para cualquiera. Simplemente no sé C.

En el estado actual de mi bifurcación, el código se compila de tal manera que vPy2 parece no verse afectado (en funcionamiento) y vPy3 al menos puede inicializarse. Recibo un error de segmento al realizar la primera solicitud, de acuerdo con este backtrace .

http://docs.python.org/py3k/howto/cporting.html describe los cambios en:

• largos/ints
• instrumentos de cuerda
• módulos

Largos/Internos

Hay una línea con dos instancias de la necesidad de pasar de PyInt_FromLong a PyLong_FromLong en request.c .

Instrumentos de cuerda

Estas definiciones deben cubrir todas las instancias de PyString .

Inicialización del módulo

http://docs.python.org/py3k/c-api/module.html proporciona más detalles.

cStringIO está en desuso

Creo que el cStringIO en request.c debe reemplazarse con PyBytes estándar.

Usé memcpy en lugar de una función cString y simplemente no sabía cómo manejar wsgi.input . Una llamada a PycString_IMPORT acaba de eliminarse sin reemplazo.

Inicialización del módulo: Whoa, eso es feo :-( Al menos podrían haber proporcionado una rutina que nos oculte la verdad :-(

Cadenas: debe usar PyUnicode para elementos de encabezado en Py3 y PyString en Py2, no PyBytes en Py3. ¿Leíste el diferencial PEP 3333?

cStringIO: Buena idea, en realidad no estoy seguro de por qué uso cStringIO (porque se conoce la longitud del contenido, por lo que un objeto de cadena estática debería ser suficiente). Pero cStringIO debe convertirse en un archivo similar antes de llamar a la aplicación WSGI, por lo que usamos el reemplazo Py3 cStringIO (lo que sea) o implementamos nuestro propio contenedor (podría hacerlo).

Por cierto, el error de segmento se debe a que el argumento pasado es un puntero NULL simplemente porque no hay un cuerpo de solicitud.

Inicialización del módulo: Whoa, eso es feo :-( Al menos podrían haber proporcionado una rutina que nos oculte la verdad :-(

Sí, tampoco ayuda a < 1KLOC. De hecho, acabo de quitar gran parte del modelo y no se ve tan mal.

Cadenas: debe usar PyUnicode para elementos de encabezado en Py3 y PyString en Py2, no PyBytes en Py3. ¿Leíste el diferencial PEP 3333?

Sí, no lo suficientemente bien. De hecho, usé la diferencia oficial y me perdí en el amarillo, casi todos los cuales se refieren a cadenas de bytes. Estás bien. Acabo de reemplazar todo el código apropiado con PyBytes y PyUnicode y revertí define a PyString para Py2x. ¿Deberían manejarse environ y/o los encabezados de esta manera ? Cuando se usa PyUnicode_FromString en HTTP/1.1 400 Bad Request telnet escupe basura pero PyBytes_FromString funciona bien..

Google no puede encontrar cStringIO y Python3 referenciados juntos con una excepción menor. Aquí hay uno . Lo acabo de quitar por completo

Esa fue la falla de segmento incorrecta, lo siento. Ya había al menos rastreado ese hasta su fuente. Este se queja de que wsgi_app no se puede llamar, lo que me lleva a pensar que estoy cerca de un servidor ejecutable. Si puedo resolverlo, podré resolver mejor los problemas de codificación.

Creo que te estás arruinando un poco con la cadena nativa/cadena Unicode, así que aquí hay algunos consejos:

Use dos archivos de encabezado, py2.h y py3.h , #definiendo todas las rutinas _usadas_ PyStr_* al tipo de datos nativo de la versión de Python ( str , = PyString en Py2 y PyUnicode en Py3). Luego defina las macros PyBytes_* en PyString en Py2 (porque el str de Py2 es el bytes de Py3). PyUnicode no se usa en absoluto usando Python 2 como enfatiza PEP 3333.

La respuesta siempre debe ser PyBytes : en Python 2, no es necesario codificar porque PyString son bytes, mientras que en Python 3 no estoy seguro de si la aplicación WSGI puede devolver PyUnicode . Si eso está permitido, esa cadena Unicode debe codificarse de alguna manera; Sin embargo, no sé qué codificación elegir.

Tu defecto de segmento es muy extraño. Supongo que arruinaste los recuentos en otro lugar... no te preocupes, todos lo hacen :)

El reemplazo actual de cStringIO (que usa memcpy ) no funciona porque cada llamada a on_body anula los datos recibidos anteriormente. Debe realizar un seguimiento de la cantidad total de memcpy datos editados (ampliar la estructura bjparser ). También elimine body = FromString(body) (línea 203) porque no es necesario y hace una copia completa del cuerpo.

¡Muchas gracias por tu esfuerzo!

Hola Angelo, ¿alguna noticia sobre el soporte de Py3?

¡Silbido! ¿Algún plan para revivir esto pronto? Si no, podría intentarlo.

No, no hay planes. Hay un puerto de otra persona https://github.com/isaiah/bjoern-py3 pero nunca lo probé, además agrega demasiado código (objeto bytesio).

Un resurgimiento de un problema anterior para hacerle saber que bjoern sigue siendo el único servidor WSGI con una implementación SO_REUSEPORT. Lástima que no podamos usarlo.

¿Está seguro? Esta es una característica estándar que todo servidor debería implementar

• Camarera
• cerezapy
• gunicornio
• Werkzeug
• meinheld

Con algunos de estos servidores, puede pasar un socket ya abierto, pero en la mayoría de los casos es tan complicado que se arrepentirá de haberlo pensado.

Para ser justos, uWSGI probablemente lo admita de alguna manera, pero la documentación me está matando.

Encontré este proyecto demasiado tarde :-( Todo este tiempo soñé con un servidor web ligero de Python, sin ningún baile alrededor de nginx. ¿Realmente no tienes planes sobre Python3?

No, pero no debería ser demasiado complicado de implementar, ¡así que no dude si tiene algo de experiencia con la API de CPython C (o está dispuesto a aprenderla)!

Espere, Bjoern no es compatible con Python 3, en 2017, ¿y este problema sigue abierto? Guau. Supongo que esta no es una opción viable para un proyecto :(

@jonashaag Lo recogí y lo hice funcionar para python3 ... no estoy seguro de si esto es lo suficientemente limpio como para fusionarlo, pero los comentarios / sugerencias son bienvenidos. :-)

https://github.com/jonashaag/bjoern/pull/104