Bjoern: Suporte ao Python 3 (PEP 3333)

Vim postar mesmo. Estou disposto, mas tenho literalmente zero experiência com extensões C. Se eu puder ser de alguma ajuda me avise. Se você puder me indicar uma ferramenta decente para ou um documento que descreva a portabilidade de extensões de 2 a 3, eu vou falar sobre isso e tentar a minha sorte.

Não deve ser muito difícil, pois não há muito que precise ser portado.

Como PyString_foo desapareceu no Py3, precisamos usar uma macro para o tipo de string nativo (chave/valores WSGI dict).

Consulte também http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ para obter ajuda geral de portabilidade Py2-to-Py3.

Qualquer dúvida, escreva um e-mail :)

Para o registro, aqui está a diferença PEP 333 para PEP 3333: http://paste.pocoo.org/show/320496/

Peço desculpas, mas não vou conseguir fazer isso sozinho. Espero que algo aqui possa ajudar alguém. Simplesmente não sei C.

No estado atual do meu fork, o código compila de tal forma que o vPy2 parece permanecer inalterado (funcionando) e o vPy3 pode pelo menos ser inicializado. Recebo uma segfault ao fazer a primeira solicitação, de acordo com este backtrace .

http://docs.python.org/py3k/howto/cporting.html descreve as alterações em:

• longos/ints
• cordas
• módulos

Longos/Ints

Há uma linha com duas instâncias de necessidade de ir de PyInt_FromLong para PyLong_FromLong em request.c .

Cordas

Essas definições devem cobrir todas as instâncias de PyString .

Inicialização do módulo

http://docs.python.org/py3k/c-api/module.html fornece mais detalhes.

cStringIO está obsoleto

Acredito que o cStringIO em request.c deve ser substituído pelo padrão PyBytes .

Eu usei memcpy no lugar de uma função cString e simplesmente não sabia como lidar com wsgi.input . Uma chamada para PycString_IMPORT acabou de ser removida sem substituição.

Inicialização do módulo: Uau, que feio :-( Eles poderiam pelo menos ter fornecido uma rotina escondendo a verdade de nós :-(

Strings: Você deve usar PyUnicode para itens de cabeçalho em Py3 e PyString em Py2, não PyBytes em Py3. Você leu o diferencial do PEP 3333?

cStringIO: Boa ideia, na verdade, não sei por que uso cStringIO (porque o comprimento do conteúdo é conhecido, portanto, um objeto de string estático deve ser suficiente). Mas cStringIO tem que ser transformado em um arquivo antes de chamar o aplicativo WSGI, então ou usamos a substituição Py3 cStringIO (o que quer que seja) ou lançamos nosso próprio wrapper (eu poderia fazer isso).

btw o segfault é porque o argumento passado é um ponteiro NULL simplesmente porque não há corpo de solicitação.

Inicialização do módulo: Uau, que feio :-( Eles poderiam pelo menos ter fornecido uma rotina escondendo a verdade de nós :-(

Sim, também não ajuda o <1KLOC. Na verdade, acabei de remover grande parte do clichê e não parece tão ruim.

Strings: Você deve usar PyUnicode para itens de cabeçalho em Py3 e PyString em Py2, não PyBytes em Py3. Você leu o diferencial do PEP 3333?

Sim, não muito bem o suficiente. Na verdade, usei o diff oficial e me perdi no amarelo, quase todos se referem a bytestrings. Você tem razão. Acabei de substituir todo o código apropriado por PyBytes e PyUnicode e reverti define para PyString para Py2x. O environ e/ou os cabeçalhos devem ser tratados assim ? Ao usar PyUnicode_FromString em HTTP/1.1 400 Bad Request telnet cospe lixo, mas PyBytes_FromString funciona bem.

O Google não consegue encontrar cStringIO e Python3 referenciados juntos com uma pequena exceção. Aqui está um . acabei de removê-lo totalmente

Essa foi a falha de segmentação errada, desculpe. Eu já tinha pelo menos rastreado aquele até sua fonte. Este reclama que wsgi_app não pode ser chamado, o que me leva a pensar que estou perto de um servidor executável. Se eu conseguir descobrir isso, poderei resolver melhor os problemas de codificação.

Eu acho que você está estragando a coisa de string nativa / string unicode um pouco, então aqui estão algumas dicas:

Use dois arquivos de cabeçalho, py2.h e py3.h , #definindo todas as rotinas _used_ PyStr_* para o tipo de dados nativo da versão Python ( str , = PyString em Py2 e PyUnicode em Py3). Em seguida, defina as macros PyBytes_* para PyString em Py2 (porque str de Py2 é bytes de Py3). PyUnicode não é usado usando Python 2 como PEP 3333 enfatiza.

A resposta deve ser sempre PyBytes : No Python 2, você não precisa fazer nenhuma codificação porque PyString é bytes, enquanto no Python 3 não tenho certeza se o aplicativo WSGI pode retornar PyUnicode . Se isso for permitido, essa string unicode deve ser codificada de alguma forma; Eu não sei qual codificação escolher, no entanto.

Seu segfault é muito estranho. Eu acho que você estragou refcounts em outro lugar ... não se preocupe, todo mundo faz :)

A substituição atual do cStringIO (usando memcpy ) está quebrada porque cada chamada para on_body substitui os dados recebidos anteriormente. Você tem que acompanhar a quantidade total de memcpy ed data (estender a estrutura bjparser ). Remova também o body = FromString(body) (linha 203) porque é desnecessário e faz uma cópia completa do corpo.

Muito obrigado por seu esforço!

Ei Angelo, alguma notícia sobre o suporte ao Py3?

Ping! Algum plano para reviver isso em breve? Se não, eu poderia dar uma facada nele.

Não, sem planos. Existe uma porta de outra pessoa https://github.com/isaiah/bjoern-py3 , mas nunca testei, além de adicionar muito código (objeto bytesio).

Um ressurgimento de um problema antigo para que você saiba que bjoern ainda é o único servidor WSGI com uma implementação SO_REUSEPORT. Pena que não podemos usar.

Tem certeza? Este é um recurso padrão que todo servidor deve implementar

• Garçonete
• CherryPy
• gunicorn
• Werkzeug
• me segurou

Com alguns desses servidores você pode passar um socket já aberto, mas na maioria dos casos é tão complicado que você vai se arrepender só de pensar nisso.

Para ser justo, o uWSGI provavelmente o suporta de alguma forma, mas a documentação está me matando.

Achei este projeto muito tarde :-( Todo esse tempo eu sonhei com um servidor web Python leve, sem nenhuma dança em torno do nginx. Você realmente não tem planos para o Python3?

Não, mas não deve ser muito complicado de implementar, então sinta-se à vontade se você tiver alguma experiência com a API C do CPython (ou estiver disposto a aprender)!

Espere, Bjoern não suporta Python 3, em 2017, e esse problema ainda está em aberto? Uau. Eu acho que esta não é uma opção viável para um projeto :(

@jonashaag Eu peguei e fiz funcionar para python3 ... não tenho certeza se isso é limpo o suficiente para ser mesclado, mas comentários/sugestões são bem-vindos. :-)

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