Bjoern: Dukungan Python 3 (PEP 3333)

Datang untuk posting yang sama. Saya bersedia tetapi benar-benar tidak memiliki pengalaman dengan ekstensi C. Jika saya dapat membantu, beri tahu saya. Jika Anda dapat mengarahkan saya ke alat yang layak untuk atau dokumen yang menjelaskan ekstensi porting dari 2 hingga 3, saya akan menuangkannya dan mencoba keberuntungan saya.

Seharusnya tidak terlalu keras karena tidak banyak yang perlu di-porting.

Karena PyString_foo hilang di Py3, kita perlu menggunakan makro untuk tipe string asli (kunci/nilai dict WSGI).

Lihat juga http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ untuk bantuan porting Py2-to-Py3 umum.

Jika Anda memiliki pertanyaan, jangan ragu untuk menulis email :)

Sebagai catatan, inilah perbedaan PEP 333 ke PEP 3333: http://paste.pocoo.org/show/320496/

Maaf, tapi saya tidak akan bisa menyelesaikan ini sendiri. Berharap sesuatu di sini bisa membantu siapa pun. Saya hanya tidak tahu C.

Dalam kompilasi kode status garpu saya saat ini sehingga vPy2 tampaknya tetap tidak terpengaruh (berfungsi) dan vPy3 setidaknya dapat diinisialisasi. Saya menerima segfault setelah membuat permintaan pertama, menurut backtrace ini .

http://docs.python.org/py3k/howto/cporting.html menjelaskan perubahan pada:

• long/ints
• string
• modul

Panjang/Int

Ada satu baris dengan dua contoh kebutuhan untuk beralih dari PyInt_FromLong ke PyLong_FromLong di request.c .

string

Definisi ini harus mencakup semua instance PyString .

Inisialisasi modul

http://docs.python.org/py3k/c-api/module.html memberikan detail yang lebih besar.

cStringIO tidak digunakan lagi

Saya percaya cStringIO di request.c harus diganti dengan standar PyBytes .

Saya menggunakan memcpy sebagai ganti satu fungsi cString dan sama sekali tidak tahu bagaimana menangani wsgi.input . Panggilan ke PycString_IMPORT baru saja dihapus tanpa penggantian.

Inisialisasi modul: Wah itu jelek :-( Setidaknya mereka bisa memberikan rutinitas menyembunyikan kebenaran dari kami :-(

String: Anda harus menggunakan PyUnicode untuk item header di Py3 dan PyString di Py2, bukan PyBytes di Py3. Apakah Anda membaca perbedaan PEP 3333?

cStringIO: Ide bagus, sebenarnya saya tidak yakin mengapa saya menggunakan cStringIO sama sekali (karena panjang konten diketahui sehingga objek string statis sudah cukup). Tetapi cStringIO harus diubah menjadi seperti file sebelum memanggil aplikasi WSGI, jadi kami menggunakan pengganti cStringIO Py3 (apa pun itu) atau kami meluncurkan pembungkus kami sendiri (saya bisa melakukannya).

btw segfault adalah karena argumen yang diteruskan adalah pointer NULL hanya karena tidak ada badan permintaan.

Inisialisasi modul: Wah itu jelek :-( Setidaknya mereka bisa memberikan rutinitas menyembunyikan kebenaran dari kami :-(

Ya itu juga tidak membantu <1KLOC. Saya sebenarnya baru saja menghapus banyak boilerplate dan itu tidak terlihat seburuk itu.

Strings: Anda harus menggunakan PyUnicode untuk item header di Py3 dan PyString di Py2, bukan PyBytes di Py3. Apakah Anda membaca perbedaan PEP 3333?

Ya, tidak cukup baik. Saya benar-benar menggunakan diff resmi dan tersesat dalam warna kuning, hampir semuanya mengacu pada bytestring. Kamu benar. Saya baru saja mengganti semua kode yang sesuai dengan PyBytes dan PyUnicode dan membalikkan define d mereka ke PyString untuk Py2x. Haruskah environ dan/atau header ditangani seperti ini ? Saat menggunakan PyUnicode_FromString pada HTTP/1.1 400 Bad Request telnet mengeluarkan sampah tapi PyBytes_FromString berfungsi dengan baik..

Google gagal menemukan cStringIO dan Python3 direferensikan bersama dengan pengecualian kecil. Ini satu . Saya baru saja menghapusnya sepenuhnya

Itu segfault yang salah, maaf. Saya sudah setidaknya melacak yang satu itu ke sumbernya. Yang ini mengeluh tentang wsgi_app tidak dapat dipanggil yang membuat saya berpikir saya dekat dengan server yang dapat dijalankan. Jika saya bisa mengetahuinya, saya akan dapat mengatasi masalah penyandian dengan lebih baik.

Saya pikir Anda sedikit mengacaukan string asli/string unicode, jadi berikut adalah beberapa tip:

Gunakan dua file header, py2.h dan py3.h , #mendefinisikan semua _used_ PyStr_* rutin ke tipe data asli versi Python ( str , = PyString di Py2 dan PyUnicode di Py3). Kemudian definisikan makro PyBytes_* menjadi PyString pada Py2 (karena str Py2 adalah bytes Py3). PyUnicode tidak digunakan sama sekali menggunakan Python 2 seperti yang ditekankan oleh PEP 3333.

Responsnya harus selalu PyBytes : Pada Python 2, Anda tidak perlu melakukan encoding apa pun karena PyString adalah byte sedangkan pada Python 3 saya tidak yakin apakah aplikasi WSGI dapat mengembalikan PyUnicode . Jika diizinkan, string unicode itu harus dikodekan entah bagaimana; Saya tidak tahu pengkodean mana yang harus dipilih.

Segfault Anda sangat aneh. Saya kira Anda mengacaukan penghitungan ulang di tempat lain ... jangan khawatir semua orang melakukannya :)

Pengganti cStringIO saat ini (menggunakan memcpy ) rusak karena setiap panggilan ke on_body menimpa data yang diterima sebelumnya. Anda harus melacak jumlah total memcpy ed data (memperpanjang struct bjparser ). Hapus juga body = FromString(body) (baris 203) karena tidak perlu dan melakukan salinan isi lengkap.

Terima kasih banyak atas usaha Anda!

Hai Angelo, ada berita tentang dukungan Py3?

ping! Adakah rencana untuk menghidupkan kembali ini dalam waktu dekat? Jika tidak, saya mungkin akan menusuknya.

Tidak, tidak ada rencana. Ada port oleh orang lain https://github.com/isaiah/bjoern-py3 tapi saya belum pernah mengujinya, ditambah lagi menambahkan terlalu banyak kode (objek bytesio).

Kebangkitan masalah lama untuk memberi tahu Anda bahwa bjoern masih merupakan satu-satunya server WSGI dengan implementasi SO_REUSEPORT. Sayang sekali kita tidak bisa menggunakannya.

Apa kamu yakin? Ini adalah fitur standar yang harus diterapkan setiap server

• Pelayan
• CherryPy
• gunicorn
• Werkzeug
• meinheld

Dengan beberapa server ini, Anda dapat melewati soket yang sudah dibuka, tetapi dalam kebanyakan kasus, soket ini sangat berbelit-belit sehingga Anda akan menyesal bahkan memikirkannya.

Agar adil, uWSGI mungkin mendukungnya dalam beberapa cara, tetapi dokumentasinya membunuh saya.

Saya menemukan proyek ini terlambat :-( Selama ini saya bermimpi tentang server web Python yang ringan, tanpa menari di sekitar nginx. Apakah Anda benar-benar tidak punya rencana tentang Python3?

Tidak, tetapi penerapannya seharusnya tidak terlalu rumit, jadi silakan jika Anda memiliki pengalaman dengan CPython C API (atau bersedia mempelajarinya)!

Tunggu, Bjoern tidak mendukung Python 3, pada tahun 2017, dan masalah ini masih terbuka? Wow. Saya kira ini bukan opsi yang layak untuk sebuah proyek :(

@jonashaag Saya mengambil dan membuatnya berfungsi untuk python3 ... tidak yakin apakah ini cukup bersih untuk digabungkan tetapi komentar/saran dipersilakan. :-)

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