Bjoern: Поддержка Python 3 (PEP 3333)

Пришел, чтобы опубликовать то же самое. Я готов, но у меня буквально нулевой опыт работы с расширениями C. Если я могу чем-то помочь, дайте мне знать. Если вы можете указать мне достойный инструмент или документ, описывающий портирование расширений с 2 ​​на 3, я изучу его и попытаю счастья.

Не должно быть слишком сложно, так как не так много нужно портировать.

Поскольку в Py3 PyString_foo больше нет, нам нужно использовать макрос для собственного строкового типа (ключ/значение WSGI dict).

Также см. http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ для общей справки по переносу Py2-to-Py3.

Если у вас есть какие-либо вопросы, не стесняйтесь писать по электронной почте :)

Для справки, вот разница между PEP 333 и PEP 3333: http://paste.pocoo.org/show/320496/

Извините, но я не смогу сделать это самостоятельно. Надеюсь, что-то здесь может помочь любому. Я просто не знаю С.

В текущем состоянии моего форка код компилируется таким образом, что vPy2 остается незатронутым (работает), а vPy3 может быть, по крайней мере, инициализирован. Я получаю segfault при первом запросе, согласно этой трассировке .

http://docs.python.org/py3k/howto/cporting.html описывает изменения:

• длинные/целые
• струны
• модули

Длинные/целые числа

Есть одна строка с двумя экземплярами необходимости перехода от PyInt_FromLong к PyLong_FromLong в request.c .

Струны

Эти определения должны охватывать все экземпляры PyString .

Инициализация модуля

http://docs.python.org/py3k/c-api/module.html содержит более подробную информацию.

cStringIO устарел

Я считаю, что cStringIO в request.c следует заменить стандартным PyBytes .

Я использовал memcpy вместо одной функции cString и просто не знал, как обращаться с wsgi.input . Вызов PycString_IMPORT был только что удален без замены.

Инициализация модуля: Вау, некрасиво :-( Могли бы хотя бы подпрограмму скрыть от нас правду :-(

Строки: вы должны использовать PyUnicode для элементов заголовка в Py3 и PyString в Py2, а не PyBytes в Py3. Вы читали разницу PEP 3333?

cStringIO: Хорошая идея, на самом деле я не уверен, почему я вообще использую cStringIO (потому что длина содержимого известна, поэтому статического строкового объекта должно быть достаточно). Но cStringIO нужно превратить в файлоподобный перед вызовом приложения WSGI, поэтому либо мы используем замену Py3 cStringIO (что бы это ни было), либо мы развертываем собственную оболочку (я мог бы это сделать).

Кстати, ошибка segfault связана с тем, что переданный аргумент является указателем NULL просто потому, что нет тела запроса.

Инициализация модуля: Вау, некрасиво :-( Могли бы хотя бы подпрограмму скрыть от нас правду :-(

Да, это действительно не помогает <1KLOC. Я на самом деле только что удалил большую часть шаблона, и это выглядит не так плохо.

Строки: вы должны использовать PyUnicode для элементов заголовка в Py3 и PyString в Py2, а не PyBytes в Py3. Вы читали разницу PEP 3333?

Да, недостаточно хорошо. Я на самом деле использовал официальный diff и потерялся в желтом, почти все из которых относятся к байтовым строкам. Ты прав. Я просто заменил весь соответствующий код на PyBytes и PyUnicode и перевернул их define на PyString для Py2x. Должны ли environ и/или заголовки обрабатываться примерно так ? При использовании PyUnicode_FromString на HTTP/1.1 400 Bad Request телнет выдает мусор, но PyBytes_FromString работает нормально..

Google не может найти ссылки на cStringIO и Python3 вместе с небольшим исключением. Вот один . Я просто удалил его полностью

Это был неправильный segfault, извините. По крайней мере, я уже проследил это до источника. Этот жалуется на то, что wsgi_app не может быть вызван, что заставляет меня думать, что я близок к работающему серверу. Если я смогу понять это, я смогу лучше решить проблемы кодирования.

Я думаю, что вы немного облажались с родной строкой/строкой юникода, поэтому вот несколько советов:

Используйте два файла заголовков, py2.h и py3.h , #определяя все _used_ подпрограммы PyStr_* в собственном типе данных версии Python ( str , = PyString на Py2 и PyUnicode на Py3). Затем определите макросы PyBytes_* для PyString на Py2 (потому что str в Py2 — это bytes в Py3). PyUnicode вообще не используется при использовании Python 2, как подчеркивается в PEP 3333.

Ответ всегда должен быть PyBytes : в Python 2 вам не нужно выполнять какое-либо кодирование, потому что PyString — это байты, тогда как в Python 3 я не уверен, может ли приложение WSGI возвращать PyUnicode . Если это разрешено, эта строка юникода должна быть каким-то образом закодирована; Однако я не знаю, какую кодировку выбрать.

Ваш segfault очень странный. Я думаю, вы перепутали счетчики ссылок где-то еще... не волнуйтесь, все это делают :)

Текущая замена cStringIO (с использованием memcpy ) не работает, поскольку каждый вызов on_body переопределяет ранее полученные данные. Вы должны отслеживать общее количество обработанных данных memcpy (расширить структуру bjparser ). Также удалите body = FromString(body) (строка 203), поскольку он не нужен и создает полную копию тела.

Большое спасибо за ваши усилия!

Эй, Анджело, есть новости о поддержке Py3?

Пинг! Есть ли планы возродить это в ближайшее время? Если нет, то я мог бы взять удар на нем.

Нет, никаких планов. Есть чужой порт https://github.com/isaiah/bjoern-py3 , но я никогда его не тестировал, к тому же он добавляет слишком много кода (объект bytesio).

Возрождение старой проблемы, чтобы вы знали, что bjoern по-прежнему является единственным сервером WSGI с реализацией SO_REUSEPORT. Жаль, что мы не можем его использовать.

Уверены ли вы? Это стандартная функция, которую должен реализовать каждый сервер.

• Официантка
• CherryPy
• оружейный рог
• Werkzeug
• майнхельд

С некоторыми из этих серверов вы можете передать уже открытый сокет, но в большинстве случаев это настолько запутанно, что вы пожалеете, даже подумав об этом.

Честно говоря, uWSGI, вероятно, каким-то образом его поддерживает, но документация меня убивает.

Я слишком поздно нашел этот проект :-( Все это время я мечтал о легковесном веб-сервере Python, без всяких танцев вокруг nginx. У вас действительно нет планов насчет Python3?

Нет, но это не должно быть слишком сложно реализовать, так что не стесняйтесь, если у вас есть некоторый опыт работы с CPython C API (или вы хотите его изучить)!

Подождите, Бьорн не поддерживает Python 3 в 2017 году, и этот вопрос все еще открыт? Ух ты. Я думаю, что это не жизнеспособный вариант для проекта :(

@jonashaag Я подобрал и заставил его работать на python3 ... не уверен, что это достаточно чисто, чтобы его можно было объединить, но комментарии / предложения приветствуются. :-)

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