Bjoern: دعم Python 3 (PEP 3333)

جاء لنشر نفسه. أنا على استعداد ولكن لديّ خبرة صفرية حرفيًا مع امتدادات C. إذا كان بإمكاني تقديم أي مساعدة ، فأعلمني بذلك. إذا كان بإمكانك توجيهي إلى أداة مناسبة أو وثيقة تصف امتدادات النقل من 2 إلى 3 ، فسأصبها وأحاول حظي.

لا ينبغي أن يكون صعبًا للغاية حيث لا يوجد الكثير مما يجب نقله.

نظرًا لأن PyString_foo ذهب في Py3 ، نحتاج إلى استخدام ماكرو لنوع السلسلة الأصلية (مفتاح / قيم WSGI deb).

راجع أيضًا 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/

أعتذر ، لكنني لن أتمكن من تحقيق ذلك بمفردي. آمل أن يكون هناك شيء ما يمكن أن يكون مفيدًا لأي شخص. أنا ببساطة لا أعرف C.

في رمز الحالة الحالي الخاص بي ، يتم تجميع رمز الحالة الحالية لـ vPy2 بحيث يبدو أنه لا يتأثر (يعمل) ويمكن على الأقل تهيئة vPy3. أتلقى Segfault عند تقديم الطلب الأول ، وفقًا لهذا التتبع الخلفي .

http://docs.python.org/py3k/howto/cporting.html يصف التغييرات على:

• longs / ints
• سلاسل
• الوحدات

Longs / Ints

هناك سطر واحد به حالتان من الحاجة للانتقال من 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؟

نعم ، ليس جيدًا بما يكفي. لقد استخدمت في الواقع فرقًا رسميًا وضاعت اللون الأصفر ، وكلها تقريبًا تشير إلى سلاسل ثنائية. أنت على حق. لقد استبدلت للتو جميع الكودات المناسبة بـ PyBytes و PyUnicode وعكست define d لهم إلى PyString لـ Py2x. هل يجب معالجة environ و / أو الرؤوس بشيء من هذا القبيل ؟ عند استخدام PyUnicode_FromString على HTTP/1.1 400 Bad Request telnet يبصق القمامة لكن PyBytes_FromString يعمل بشكل جيد ..

فشل Google في العثور على cStringIO و Python3 المشار إليهما معًا مع استثناء بسيط. هذا واحد . أنا فقط أزلته بالكامل

كان هذا هو segfault الخاطئ ، آسف. كنت قد تتبعت ذلك بالفعل على الأقل إلى مصدره. يشتكي هذا الشخص من عدم إمكانية استدعاء wsgi_app مما يقودني إلى الاعتقاد بأنني قريب من خادم قابل للتشغيل. إذا تمكنت من معرفة ذلك ، فسأكون قادرًا على حل مشكلات الترميز بشكل أفضل.

أعتقد أنك تتعطل شيئًا ما عن السلسلة النصية / سلسلة unicode الأصلية قليلاً ، لذا إليك بعض النصائح:

استخدم ملفي رأس ، py2.h و py3.h ، # تعريف جميع إجراءات _ used_ PyStr_* لنوع البيانات الأصلية لإصدار Python ( str ، = PyString على Py2 و PyUnicode على Py3). ثم حدد وحدات ماكرو PyBytes_* لـ PyString في Py2 (لأن Py2 str هو Py3's bytes ). لا يتم استخدام PyUnicode إطلاقًا باستخدام Python 2 كما يؤكد PEP 3333.

يجب أن تكون الاستجابة دائمًا PyBytes : في Python 2 ، لست مضطرًا للقيام بأي تشفير لأن PyString عبارة عن بايت بينما في Python 3 لست متأكدًا مما إذا كان تطبيق WSGI قد يعيد PyUnicode . إذا كان ذلك مسموحًا به ، فيجب ترميز سلسلة unicode بطريقة ما ؛ ومع ذلك ، لا أعرف الترميز الذي يجب اختياره.

سيغفولت الخاص بك غريب جدا. أعتقد أنك أخطأت في إعادة العد في مكان آخر ... لا تقلق على الجميع :)

استبدال cStringIO الحالي (باستخدام memcpy ) معطل لأن كل مكالمة إلى on_body تتجاوز البيانات المستلمة سابقًا. يجب عليك تتبع المبلغ الإجمالي لبيانات ed memcpy bjparser الهيكل). قم أيضًا بإزالة body = FromString(body) (السطر 203) لأنه غير ضروري ويقوم بعمل نسخة كاملة للمحتوى.

أشكركم جزيل الشكر على ما تبذلونه من جهد لك!

مرحبًا Angelo ، هل من أخبار عن دعم Py3؟

بينغ! أي خطط لإحياء هذا في أي وقت قريب؟ إذا لم يكن الأمر كذلك ، فقد أقوم بطعنة في ذلك.

كلا ، لا توجد خطط. يوجد منفذ بواسطة شخص آخر https://github.com/isaiah/bjoern-py3 لكني لم أختبره مطلقًا ، بالإضافة إلى أنه يضيف الكثير من التعليمات البرمجية (كائن bytesio).

إصدار قديم لإعلامك بأن bjoern لا يزال خادم WSGI الوحيد مع تنفيذ SO_REUSEPORT. سيء للغاية لا يمكننا استخدامه.

هل أنت متأكد؟ هذه ميزة قياسية يجب على كل خادم تنفيذها

• نادلة
• الكرز
• جونيكورن
• ويركزوغ
• عين

باستخدام بعض هذه الخوادم ، يمكنك تمرير مقبس مفتوح بالفعل ، ولكن في معظم الحالات يكون الأمر معقدًا للغاية ، وستندم حتى على التفكير فيه.

لكي نكون منصفين ، ربما تدعم UWSGI ذلك بطريقة ما ، لكن الوثائق تقتلني.

لقد وجدت هذا المشروع متأخرًا جدًا :- (طوال هذا الوقت كنت أحلم بخادم ويب Python خفيف الوزن ، بدون أي رقصات حول nginx. هل حقًا ليس لديك أي خطط حول Python3؟

لا ، ولكن لا ينبغي أن يكون التنفيذ معقدًا للغاية ، لذا لا تتردد إذا كان لديك بعض الخبرة في CPython C API (أو كنت على استعداد لتعلمها)!

انتظر ، Bjoern لا يدعم Python 3 ، في عام 2017 ، وما زالت هذه المشكلة مفتوحة؟ رائع. أعتقد أن هذا ليس خيارًا قابلاً للتطبيق لمشروع :(

jonashaag التقطته وجعلته يعمل مع python3 ... لست متأكدًا مما إذا كان هذا نظيفًا بما يكفي ليتم دمجه ولكن التعليقات / الاقتراحات مرحب بها. :-)

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