Bjoern: पायथन 3 समर्थन (पीईपी 3333)

वही पोस्ट करने आया था। मैं तैयार हूं लेकिन सी एक्सटेंशन के साथ सचमुच शून्य अनुभव है। अगर मैं कोई मदद कर सकता हूं तो मुझे बताएं। यदि आप मुझे 2 से 3 तक पोर्टिंग एक्सटेंशन का वर्णन करने वाले एक अच्छे टूल या दस्तावेज़ के बारे में बता सकते हैं तो मैं उस पर डालूंगा और अपनी किस्मत आजमाऊंगा।

बहुत कठिन नहीं होना चाहिए क्योंकि बहुत कुछ नहीं है जिसे पोर्ट करने की आवश्यकता है।

चूंकि PyString_foo Py3 में चला गया है, हमें मूल स्ट्रिंग प्रकार (WSGI dict key/values) के लिए मैक्रो का उपयोग करने की आवश्यकता है।

सामान्य Py2-to-Py3 पोर्टिंग सहायता के लिए http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ भी देखें।

यदि आपके कोई प्रश्न हैं तो बेझिझक ई-मेल लिखें :)

रिकॉर्ड के लिए, यहां पीईपी 333 से पीईपी 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 से बदला जाना चाहिए।

मैंने एक cString फ़ंक्शन के स्थान पर memcpy का उपयोग किया और बस यह नहीं पता था कि wsgi.input को कैसे संभालना है। PycString_IMPORT पर कॉल को बिना बदले ही हटा दिया गया है।

मॉड्यूल इनिशियलाइज़ेशन: वाह जो बदसूरत है :-( वे कम से कम हमसे सच्चाई छुपाते हुए एक रूटीन प्रदान कर सकते थे :-(

स्ट्रिंग्स: आपको Py3 में हेडर आइटम के लिए PyUnicode और Py2 में PyString का उपयोग करना चाहिए, न कि Py3 में PyBytes का। क्या आपने पीईपी 3333 अंतर पढ़ा?

cStringIO: अच्छा विचार, वास्तव में मुझे यकीन नहीं है कि मैं cStringIO का उपयोग क्यों करता हूं (क्योंकि सामग्री की लंबाई ज्ञात है इसलिए एक स्थिर स्ट्रिंग ऑब्जेक्ट पर्याप्त होना चाहिए)। लेकिन WSGI एप्लिकेशन को कॉल करने से पहले cStringIO को एक फ़ाइल की तरह बदलना होगा, इसलिए या तो हम Py3 cStringIO प्रतिस्थापन (जो कुछ भी है) का उपयोग करें या हम अपना स्वयं का रैपर रोल आउट करें (मैं ऐसा कर सकता था)।

बीटीडब्ल्यू सेगफॉल्ट इसलिए है क्योंकि पारित तर्क केवल एक पूर्ण सूचक है क्योंकि कोई अनुरोध निकाय नहीं है।

मॉड्यूल इनिशियलाइज़ेशन: वाह जो बदसूरत है :-( वे कम से कम हमसे सच्चाई छुपाते हुए एक रूटीन प्रदान कर सकते थे :-(

हाँ, यह वास्तव में <1KLOC की भी मदद नहीं करता है। मैंने वास्तव में बॉयलरप्लेट को बहुत हटा दिया है और यह लगभग उतना बुरा नहीं दिखता है।

स्ट्रिंग्स: आपको Py3 में हेडर आइटम्स के लिए PyUnicode और Py2 में PyString का उपयोग करना चाहिए, Py3 में PyBytes का नहीं। क्या आपने पीईपी 3333 अंतर पढ़ा?

हाँ, काफी अच्छा नहीं है। मैंने वास्तव में आधिकारिक अंतर का इस्तेमाल किया और पीले रंग में खो गया, जिनमें से लगभग सभी बाइटस्ट्रिंग्स को संदर्भित करते हैं। तुम सही कह रही हो। मैंने अभी सभी उपयुक्त कोड को PyBytes और PyUnicode से बदल दिया है और define d उन्हें Py2x के लिए PyString में उलट दिया है। क्या environ और/या शीर्षलेखों को इस तरह कुछ संभाला जाना चाहिए? PyUnicode_FromString का उपयोग करते समय $ HTTP/1.1 400 Bad Request टेलनेट कचरा थूकता है लेकिन PyBytes_FromString ठीक काम करता है ..

Google मामूली अपवाद के साथ संदर्भित cStringIO और Python3 को खोजने में विफल रहता है। यहाँ एक है । मैंने अभी इसे पूरी तरह से हटा दिया है

वह गलत सेगफॉल्ट था, क्षमा करें। मैंने पहले ही कम से कम उसके स्रोत का पता लगा लिया था। यह wsgi_app कॉल करने योग्य नहीं होने के बारे में शिकायत करता है जिससे मुझे लगता है कि मैं एक रननेबल सर्वर के करीब हूं। अगर मैं यह पता लगा सकता हूं कि मैं एन्कोडिंग मुद्दों को बेहतर ढंग से हल करने में सक्षम हूं।

मुझे लगता है कि आप देशी स्ट्रिंग/यूनिकोड स्ट्रिंग चीज़ को थोड़ा खराब कर रहे हैं, इसलिए यहां कुछ युक्तियां दी गई हैं:

दो शीर्षलेख फ़ाइलों का उपयोग करें, py2.h और py3.h , # सभी _used_ PyStr_* रूटीन को Python संस्करण के मूल डेटा प्रकार ( str , = PyString Py2 पर और PyUnicode Py3 पर)। फिर Py2 पर PyBytes_* मैक्रोज़ को PyString में परिभाषित करें (क्योंकि Py2 का str Py3 का bytes है)। PyUnicode का उपयोग Python 2 का उपयोग करके बिल्कुल भी नहीं किया जाता है क्योंकि PEP 3333 जोर देता है।

प्रतिक्रिया हमेशा PyBytes होनी चाहिए: पायथन 2 पर, आपको कोई एन्कोडिंग करने की आवश्यकता नहीं है क्योंकि PyString बाइट्स है जबकि पायथन 3 पर मुझे यकीन नहीं है कि WSGI एप्लिकेशन PyUnicode वापस आ सकता है या नहीं

आपका सेगफॉल्ट बहुत अजीब है। मुझे लगता है कि आपने कहीं और गड़बड़ी की है ... चिंता न करें हर कोई करता है :)

वर्तमान cStringIO प्रतिस्थापन ( memcpy का उपयोग करके) टूट गया है क्योंकि on_body पर प्रत्येक कॉल पहले प्राप्त डेटा को ओवरराइड करता है। आपको memcpy एड डेटा की कुल राशि का ट्रैक रखना होगा ( bjparser संरचना का विस्तार करें)। body = FromString(body) (पंक्ति 203) को भी हटा दें क्योंकि यह अनावश्यक है और पूरी बॉडी कॉपी करता है।

आपके प्रयास के लिए बहुत - बहुत धन्यवाद!

अरे एंजेलो, Py3 समर्थन पर कोई खबर?

गुनगुनाहट! इसे जल्द ही किसी भी समय पुनर्जीवित करने की कोई योजना है? यदि नहीं, तो मैं उस पर वार कर सकता हूं।

नहीं, कोई योजना नहीं। किसी और के द्वारा एक बंदरगाह है https://github.com/isaiah/bjoern-py3 लेकिन मैंने कभी इसका परीक्षण नहीं किया है, साथ ही यह बहुत अधिक कोड (बाइट्सियो ऑब्जेक्ट) जोड़ता है।

एक पुरानी समस्या का पुनरुद्धार आपको यह बताने के लिए कि bjoern अभी भी SO_REUSEPORT कार्यान्वयन वाला एकमात्र WSGI सर्वर है। बहुत बुरा हम इसका इस्तेमाल नहीं कर सकते।

क्या आपको यकीन है? यह एक मानक विशेषता है जिसे प्रत्येक सर्वर को लागू करना चाहिए

• वेट्रेस
• चेरीपी
• गनिकोर्न
• Werkzeug
• मीनहेल्ड

इनमें से कुछ सर्वरों के साथ आप पहले से खोले गए सॉकेट को पास कर सकते हैं, लेकिन ज्यादातर मामलों में यह इतना जटिल है कि आप इसके बारे में सोचकर भी पछताएंगे।

निष्पक्ष होने के लिए यूडब्ल्यूएसजीआई शायद किसी तरह से इसका समर्थन करता है, लेकिन दस्तावेज मुझे मार रहा है।

मुझे यह प्रोजेक्ट बहुत देर से मिला :-( इस समय मैं हल्के पायथन वेब-सर्वर के बारे में सपना देख रहा था, बिना nginx के आसपास नृत्य किए। क्या आपके पास वास्तव में Python3 के बारे में कोई योजना नहीं है?

नहीं, लेकिन इसे लागू करने के लिए बहुत जटिल नहीं होना चाहिए, इसलिए यदि आपके पास CPython C API के साथ कुछ अनुभव है (या इसे सीखने के इच्छुक हैं) तो बेझिझक महसूस करें!

रुको, ब्योर्न 2017 में पायथन 3 का समर्थन नहीं करता है, और यह मुद्दा अभी भी खुला है? बहुत खूब। मुझे लगता है कि यह एक परियोजना के लिए व्यवहार्य विकल्प नहीं है :(

@jonashaag मैंने उठाया और इसे python3 के लिए काम कर रहा है ... सुनिश्चित नहीं है कि यह विलय करने के लिए पर्याप्त साफ है लेकिन टिप्पणियों/सुझावों का स्वागत है। :-)

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