Bjoern: Prise en charge de Python 3 (PEP 3333)

Entré pour poster le même. Je suis prêt mais n'ai littéralement aucune expérience avec les extensions C. Si je peux être utile, faites-le moi savoir. Si vous pouvez m'indiquer un outil décent ou un document décrivant le portage des extensions de 2 à 3, je vais y jeter un coup d'œil et tenter ma chance.

Cela ne devrait pas être trop difficile car il n'y a pas grand chose à porter.

Comme PyString_foo a disparu dans Py3, nous devons utiliser une macro pour le type de chaîne natif (clé/valeurs dict WSGI).

Voir également http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ pour une aide générale sur le portage Py2-to-Py3.

Si vous avez des questions, n'hésitez pas à écrire un e-mail :)

Pour mémoire, voici le diff PEP 333 à PEP 3333 : http://paste.pocoo.org/show/320496/

Toutes mes excuses, mais je ne vais pas être en mesure d'accomplir cela par moi-même. J'espère que quelque chose ici pourra être utile à tout le monde. Je ne connais tout simplement pas C.

Dans l' état actuel de mon fork, le code se compile de telle sorte que vPy2 semble rester inchangé (fonctionnel) et vPy3 peut au moins être initialisé. Je reçois une erreur de segmentation lors de la première demande, selon cette backtrace .

http://docs.python.org/py3k/howto/cporting.html décrit les modifications apportées :

• longs/ints
• cordes
• modules

Longs/Entiers

Il y a une ligne avec deux instances d'un besoin d'aller de PyInt_FromLong à PyLong_FromLong dans request.c .

Cordes

Ces définitions doivent couvrir toutes les instances de PyString .

Initialisation des modules

http://docs.python.org/py3k/c-api/module.html fournit plus de détails.

cStringIO est obsolète

Je crois que le cStringIO dans request.c devrait être remplacé par le standard PyBytes .

J'ai utilisé memcpy à la place d'une fonction cString et je ne savais tout simplement pas comment gérer wsgi.input . Un appel à PycString_IMPORT vient d'être supprimé sans remplacement.

Initialisation du module : Ouah c'est moche :-( Ils auraient au moins pu nous fournir une routine nous cachant la vérité :-(

Chaînes : vous devez utiliser PyUnicode pour les éléments d'en-tête dans Py3 et PyString dans Py2, et non PyBytes dans Py3. Avez-vous lu le diff PEP 3333?

cStringIO : Bonne idée, en fait je ne sais pas du tout pourquoi j'utilise cStringIO (parce que la longueur du contenu est connue donc un objet chaîne statique devrait suffire). Mais cStringIO doit être transformé en un fichier semblable avant d'appeler l'application WSGI, donc soit nous utilisons le remplacement Py3 cStringIO (quel qu'il soit), soit nous déployons notre propre wrapper (je pourrais le faire).

btw le segfault est dû au fait que l'argument passé est un pointeur NULL simplement parce qu'il n'y a pas de corps de requête.

Initialisation du module : Ouah c'est moche :-( Ils auraient au moins pu nous fournir une routine nous cachant la vérité :-(

Ouais, ça n'aide vraiment pas non plus le < 1KLOC. En fait, je viens de retirer une grande partie du passe-partout et ça n'a pas l'air aussi mauvais.

Chaînes : vous devez utiliser PyUnicode pour les éléments d'en-tête dans Py3 et PyString dans Py2, et non PyBytes dans Py3. Avez-vous lu le diff PEP 3333?

Ouais, pas assez bien. En fait, j'ai utilisé le diff officiel et je me suis perdu dans le jaune, qui fait presque tous référence à des chaînes d'octets. Vous avez raison. Je viens de remplacer tout le code approprié par PyBytes et PyUnicode et de les inverser define en PyString pour Py2x. Le environ et/ou les en-têtes doivent-ils être traités comme ceci ? Lors de l'utilisation PyUnicode_FromString sur HTTP/1.1 400 Bad Request telnet crache des ordures mais PyBytes_FromString fonctionne bien.

Google ne parvient pas à trouver cStringIO et Python3 référencés avec une exception mineure. En voici un . je viens de le supprimer entièrement

C'était la mauvaise erreur de segmentation, désolé. J'avais déjà au moins tracé celui-là jusqu'à sa source. Celui-ci se plaint du fait que wsgi_app n'est pas appelable, ce qui m'amène à penser que je suis proche d'un serveur exécutable. Si je peux comprendre cela, je serai en mesure de mieux résoudre les problèmes d'encodage.

Je pense que vous vous trompez un peu avec la chaîne native / chaîne Unicode, alors voici quelques conseils:

Utilisez deux fichiers d'en-tête, py2.h et py3.h , #définissant toutes les routines _utilisées_ PyStr_* au type de données natif de la version Python ( str , = PyString sur Py2 et PyUnicode sur Py3). Définissez ensuite les macros PyBytes_* à PyString sur Py2 (parce que str de Py2 est bytes de Py3). PyUnicode n'est pas du tout utilisé avec Python 2 comme le souligne la PEP 3333.

La réponse doit toujours être PyBytes : Sur Python 2, vous n'avez pas à faire d'encodage car PyString est des octets alors que sur Python 3 je ne sais pas si l'application WSGI peut retourner PyUnicode . Si cela est autorisé, cette chaîne unicode doit être encodée d'une manière ou d'une autre ; Par contre, je ne sais pas quel encodage choisir.

Votre erreur de segmentation est très bizarre. Je suppose que vous avez foiré les refcounts ailleurs ... ne vous inquiétez pas, tout le monde le fait :)

Le remplacement actuel de cStringIO (utilisant memcpy ) est rompu car chaque appel à on_body remplace les données précédemment reçues. Vous devez garder une trace du montant total de données memcpy ed (étendez la structure bjparser ). Supprimez également le body = FromString(body) (ligne 203) car il est inutile et fait une copie complète du corps.

Merci beaucoup pour ton effort!

Hey Angelo, des nouvelles sur le support de Py3 ?

Ping ! Avez-vous l'intention de faire revivre cela bientôt ? Sinon, je pourrais tenter ma chance.

Non, pas de plans. Il y a un port par quelqu'un d'autre https://github.com/isaiah/bjoern-py3 mais je ne l'ai jamais testé, en plus il ajoute trop de code (objet bytesio).

Un ancien rappel de problème pour vous faire savoir que bjoern est toujours le seul serveur WSGI avec une implémentation SO_REUSEPORT. Dommage qu'on ne puisse pas l'utiliser.

Es-tu sûr? Il s'agit d'une fonctionnalité standard que chaque serveur devrait implémenter

• Serveuse
• CerisePy
• gunicorne
• Werkzeug
• meinheld

Avec certains de ces serveurs, vous pouvez passer un socket déjà ouvert, mais dans la plupart des cas, c'est tellement compliqué que vous regretterez même d'y avoir pensé.

Pour être juste, uWSGI le prend probablement en charge d'une manière ou d'une autre, mais la documentation me tue.

J'ai trouvé ce projet trop tard :-( Pendant tout ce temps, je rêvais d'un serveur Web Python léger, sans aucune danse autour de nginx. N'avez-vous vraiment aucun projet concernant Python3 ?

Non, mais cela ne devrait pas être trop compliqué à mettre en œuvre, alors n'hésitez pas si vous avez de l'expérience avec l'API CPython C (ou si vous êtes prêt à l'apprendre) !

Attendez, Bjoern ne prend pas en charge Python 3, en 2017, et ce problème est toujours ouvert ? Wow. Je suppose que ce n'est pas une option viable pour un projet :(

@jonashaag J'ai ramassé et l'ai fait fonctionner pour python3 ... je ne sais pas si c'est assez propre pour être fusionné mais les commentaires/suggestions sont les bienvenus. :-)

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