Arquivo da tag: django

Django 1.4 é disponibilizado

Fonte: IMasters


Após meses de trabalho, o Django 1.4 foi liberado. O anúncio foi feito no blog do framework pelo desenvolvedor James Bennet.

Segundo ele, a versão é a última oficial do Django com suporte para o Python 2.5. Quando o Django 1.5 for lançado, a versão mínima do Python requerida será a 2.6, embora será possível a utilização do Django 1.4, durante seu suporte de ciclo de segurança, caso alguém precise de suporte para o Python 2.5.

Detalhes e novidades sobre o Django 1.4 podem ser encontrados nas notas de lançamento, e ele pode ser baixado neste link.

Otimizando o Django Views com C++

Fonte: IMasters

Texto original disponível em: http://www.jeffknupp.com/blog/2012/02/15/optimizing-django-views-with-c-plus-plus/


No meu artigo anterior, esbocei o método que vai sobre o perfil de um aplicativo Django. Utilizei uma view do linkrdr como um exemplo. Ela é responsável por agregar, classificar e ordenar todos os links de feeds de um usuário (RSS, Atom, Twitter, etc). O código a partir do envio da mensagem foi uma implementação simplista e inicial do panorama. Tenho, no entanto, um algoritmo de pontuação muito mais robusto, escrito em Python, que eu planejava utilizar no site.

Você pode ter percebido a palavra “planejado” ali, né? Pois é, o algoritmo se revelou muito lento. Mais do que eu consideraria aceitável. Depois de pensar em várias mudanças arquitetônicas que poderiam ser feitas para resolver o problema, cheguei em uma solução um tanto radical para um desenvolvedor Django: eu implementei a visão em C++.

Sei que nem todo desenvolvedor Django sabe C++ – e não precisa -, mas aqueles que sabem precisam perceber que é uma ferramenta viável quando Python está muito lento. Mas, eventualmente, você pode chegar a um ponto onde não é possível realmente otimizar o seu código Python mais. Neste caso, o perfil mostra que a maioria de seu tempo é gasto em chamadas de bibliotecas Python. Depois de bater nesse ponto, ou você escreve um algoritmo ineficiente ou você tem um problema não adequado para Python.

Quando percebi que tinha atingido esse ponto com o meu código de visão, entrei em pânico. “O que mais há para fazer?”, me perguntava. Então me lembrei de um projeto de trabalho onde havia escrito alguns códigos C++ que fazem interface com o Python. De uma perspectiva técnica, não havia nada me impedindo de implementar alguns aspectos do meu app Django em C++ (além do fato de que ele é torturante para escrever quando se trata do Python). Uma vez que linkrdr é um projeto de uma só pessoa, não existem companheiros que precisam aprender o código. Sendo assim, eu sou livre para implementá-lo como eu desejar.

Configurando

Tendo escrito um código “puro” C++/Python de interoperabilidade Python antes, e não querendo ver Py_XDecRef novamente, decidi usar boost::Python. Para começar, eu me certifiquei de que tinha as bibliotecas mais recentes do Boost e uma versão atualizada de gcc para que eu pudesse usar as características C++ 11, que são de fato muito boas. Depois de construir a versão mais recente da biclioteca boost::python, eu realemnte aprendi a lidar com isso. E ela acabou sendo extremamente fácil.

O boost::python envolve uma série de tipos de dados em Python para você: “object” representa um objeto Python genérico, “lista” é uma lista, e assim por diante. Como o Python é tipado dinamicamente, não há realmente muitos lugares inteiramente dele. “Tudo é um objeto” significa que tudo é um boost::python::object e pode ser acessado desta forma.

Além de wrappers primitivo, o boost fornece um mecanismo claro e conciso para fazer classes e funções C++ visíveis para Python. Eu tinha uma classe simples no código de entrada do nome anterior do meu LinkScore. Era basicamente uma estrutura C com uma lista de objetos e um interger. O código C++ é:

using namespace boost::python;

class LinkScore
{
public:
LinkScore() {}
LinkScore(const object& link, int score) : score_(score)
{
links_.append(link);
}
list links_;
int score_;
};

Se você está pensando que meus data members deveriam ser privados, adivinhem: eu não me importo. Essa é alegria de trabalhar em código que só você vai usar. Você pede escrevê-lo e usá-lo como quiser.

Os detalhes

Enfim, o código com o qual o boost:python pode chamar o Python é:

class_<LinkScore>("LinkScore", init<object, int>())
.def_readwrite("links", &LinkScore::links_)
.def_readwrite("score", &LinkScore::score_);

Realmente, não poderia ser mais simples. A maneira de conseguir isso <Python.h> envolve a definição de uma estrutura com quarenta valores para declarar cada classe. Fiquei feliz em não ter que me preocupar com isso.

O atual código para a minha view é uma função gratuita chamada get_scores. Aqui está um breve trecho:

using namespace boost::python;
using namspace std;

class CompareObject {
public:
bool  operator()(const LinkScore& l, const LinkScore& r) { return l.score_ > r.score_; }
};

list get_scores(object links)
{
object utility = import("links.utility");
set<LinkScore, CompareObject> seen_links;
list python_seen_links;
for (int i = 0; i < len(links); ++i)
{
const object& link = links[i];
LinkScore score = LinkScore(link, score_link (link, links));
auto iter = seen_links.find(score);

if (iter != seen_links.end())
{
// Do stuff
}
else
{
// Do other stuff
}
}
// TODO: Optimize this
for (auto i = seen_links.begin(); i != seen_links.end(); ++i)
{
python_seen_links.append(*i);
}
return python_seen_links;

Se você conhece C++ e Python, é quase como ler um mix dos dois. A descrição acima, no entanto, é válida para o código C++ e é a interface que o Python usa para chamar minha biblioteca de pontuação. Para expor essa função para o Python, tudo que é necessário é def (“get_score”, get_score); dentro de um bloco BOOST_PYTHON_MODULE, que nomeia o módulo a ser importado.

Quando terminei de escrever o código C++, eu o compilei usando o gcc com a ferramenta de biuld bjam da biblicota boots; defini o meu LD_LIBRARY_PATH para captar o libboost_Python.so e liguei uma shell do manage.py (na verdade, um “shell_plus”). Usei o módulo cProfile para comparar a versão do C++ da view com a versão do Python da view. Os resultados foram satisfatórios: um aumento de oito vezes na velocidade com a versão C++.

Para acionar o código C++, eu só precisava ter certeza que o .so gerado estiva em minha PYTHON_PATH. Assim, poderia importá-lo como uma biblioteca normal do Python. Acrescentei-o ao meu views.py e meus testes unitários rodaram. Depois disso, comitei tudo e coloquei o novo código através dos seus passos no servidor de desenvolvimento web. O tempo de resposta melhorou visivelmente, com a view funcionando instantaneamente.

Wrap Up

Sei que esta não é uma opção de otimização disponível para todos, mas é uma opção interessante. O Python é uma linguagem fantástica e o Django é um framework muito bom. No geral, estou bastante contente com os resultados e como foi fácil de implementar. Me absterei de escrever mais código C++ para linkrdr, a menos que seja absolutamente necessário. É bom saber, no entanto, que a opção está lá.

Django divulga planos para migrar para Python 3

Fonte: IMasters

Com informações de The H

Os desenvolvedores do Django publicaram planos sobre como eles migrarão seu framework baseado em Python para o Python 3. Vários usuários apontaram a falta de suporte para o Python 3 no Django como a razão para não migrarem para a nova versão da linguagem. Trabalhando com a equipe do Python, eles optaram por uma migração organizada, usando o Python 2.6 como ponto de partida.

Primeiramente, os desenvolvedores pretendem diminuir o uso de versões antigas 2.x do Python, até que a versão mínima do Python pelo Django seja a 2.6. Essa versão é a base da transição, já que foi desenvolvida para ser uma ponte para o Python 3, uma vez que muitas funcionalidades do mais novo Python foram portadas novamente para ela, que inclui ferramentas para dar suporte para a migração de código para o Python 3.

O ainda não lançado Django 1.4 não terá mais suporte para Python 2.4, e o Django 1.5, por sua vez, deixará de suportar o Python 2.5 mais para frente. Além disso, o Django 1.5 vai adicionar suporte experimental para o Python 3.x, principalmente a versão 3.3. Logo, o Django 1.5 será o início do processo de portar o código base do Django para o Python 3.

Detalhes sobre essa transição ainda não estão disponíveis, mas, segundo os desenvolvedores do Django, o Python 3 é o futuro da linguagem Python e, em apoio a isso, o Django continuará comprometido em alcançar a compatibilidade com o Python.

Django 1.4 beta 1: uma previsão da nova versão do maior framework Python

Fonte: Eder Magalhães/IMasters

A comunidade de desenvolvimento do Django anunciou a versão 1.4 beta 1, uma amostra com as novas funcionalidades e melhorias da próxima versão do Django. O Django é um popular framework open source, para desenvolvimento web utilizando Python. Disponibiliza uma estrutura alto-nível para Mapeamento Objeto/Relacional (ORM, na sigla em inglês), além da definição de templates visuais, criação automática de interfaces para administração de conteúdo, e outras características como foco em produtividade.

A nova versão do Django implementa o conjunto extenso de melhorias, entre elas:

  • Integração com ferramentas de testes. O Django agora pode ser integrado a ferramentas de testes direto do navegador. Com a nova classe LiveServerTestCase programadores poderão escrever casos de testes que operam como um serviço e são acionados no navegador por clientes/scripts de testes, como o Selenium.
  • Novidades em ORM. Através do método bulk_create, o mecanismo de ORM do Django suporta a criação de múltiplos objetos, aumentando muito a performance ao utilizar muitas instâncias de objetos. Já com o novo método prefetch_related é possível obter relacionamentos complexos entre objetos de forma mais eficaz. Outra novidade no ORM do Django é o suporte a locks pessimistas de registros na base de dados, através do método select_for_update.
  • Melhorias em segurança. O Django 1.4 introduz um novo mecanismo para armazenamento de senhas com algoritmo PBKDF2 e codificação SHA256, mais seguro que a alternativa anterior (o Django 1.3 utiliza SHA1). Também foram implementadas APIs de criptografia, permitindo a manipulação de cookies assinados.
  • Internacionalização. Com o novo método i18n_patterns a nova versão do framework utiliza um prefixo na URLs mapeadas da aplicação, identificando o idioma em que o conteúdo deve ser apresentado. Adicionalmente é possível traduzir o conteúdo de uma URL através do método ugettext_lazy.
  • Templates. A versão 1.4 traz a função assignment_tag para simplificar a criação de tags que manipulam variáveis no contexto da aplicação. Outra novidade é que, a partir de agora, exceções lançadas em modo de depuração não são mais encapsuladas em TemplateSyntaxError.

Por fim, é importante notar que a partir da versão 1.4, o Django passa a suportar o Python 2.5 como a versão mínima da linguagem.

Para experimentar o Django 1.4 beta 1, é necessário realizar o download no site do projeto. O objetivo é que, ao testarem a versão beta, os desenvolvedores colaborem, fornecendo o feedback sobre as funcionalidades implementadas além de identificar e corrigir eventuais bugs. O lançamento do Django 1.4 final deve ocorrer até o fim de março deste ano.

PySide e aplicações web

Recentemente eu me vi obrigado a mudar a linha de desenvolvimento de um projeto meu, e pra isso eu resolvi abandonar muita coisa e me dedicar de fato ao Python. Eu sempre soube que a comunidade do Python era muito grande e bem entusiasmada, mas me surpreendi com o quanto eu consegui progredir em tão pouco tempo, tá dando tempo até de postar no blog e adiantar tempo no cronograma.

Enfim, minha situação é a seguinte: pretendo fazer um sistema web, com a interface inteira em HTML e um back-end qualquer (tá, eu vou escolher o Django, mas você que está lendo é livre para escolher qualquer outro), mas que o usuário final veja esse sistema como um software comum, com atalho na área de trabalho, janelinha dedicada e tudo mais. Até ai eu poderia usar um Adobe AIR da vida, mas o problema é que eu preciso me comunicar com alguns recursos do PC, tipo comandos no terminal, janela de autenticação, ou até mesmo um “visual” mais desktop. Então me surgiram diversas opções pra Mono, Python, e até o C++… Mas quem me agradou de verdade foi o PySide, uma binding oficial do Qt em Python.

O que me convenceu a gostar do PySide foi a facilidade de implementar instâncias derivadas de QObject dentro de um QWebView, essas instâncias ficam acessíveis no objeto window do JavaScript. Suponhamos que eu tenha uma classe mais ou menos assim:

from PySide import QtCore

class MyJSObject(QtCore.QObject):
    @QtCore.Slot()
    def teste(self):
         print "Hello from JavaScript"

Com essa classe criada, eu posso adicioná-la ao frame principal de um determinado QWebView da seguinte maneira:

	meuBrowser = QtWebKit.QWebView()
	meuBrowser.load(QtCore.QUrl('http://localhost/minhapagina.htm'))
	meuBrowser.page().mainFrame().addToJavaScriptWindowObject('myjs', MyJSObject())

Experimente fazer uma chamada no JavaScript ao objeto window[“myjs”].teste(), ou se você preferir injetar um código JavaScript para esse fim, também é possível através do evaluateJavaScript():

	meuBrowser.page().mainFrame().evaluateJavaScript('window["myjs"].teste()')

Agora é só conferir o terminal do Python pra você ver o print do método teste() funcionando. A partir desse conceito você tem uma gama de opções para desenvolver aplicações ricas usando todo potencial do Python e do que há de melhor na web ao mesmo tempo.

Não se esqueça de os métodos declarados dentro da sua classe derivada de QObject precisam do decorator Slot para ficarem visíveis no JavaScript. Para tirar mais dúvidas quanto as slots e aos signals, leia esse trecho da documentação oficial.

Dedico esse artigo ao pessoal do canal #python na rede vIRCio, em especial ao Rafaelzinhu por ter me indicado esse servidor IRC e ao vitorlobo com o blog Pythonando, que serviu de ótima referência pra que eu pudesse destrinchar bastante coisa sobre o PySide.

Fonte: TimoteoRamos