Python import
Postado por Osvaldo Santana
Ao começar a trabalhar no desenvolvimento do Python para Maemo no INdT a gente percebeu que o CPython não apresentava problemas sérios de performance no 770 e que uma das poucas coisas que realmente incomodava era a demora para importar alguns módulos importantes na plataforma (principalmente o PyGTK).
Quando iniciamos a segunda fase do nosso projeto decidimos atacar a otimização da plataforma Python em duas frentes: uma na linha de pesquisa que daria resultados a longo prazo e uma outra com foco mais prático no CPython.
Eu assumi a segunda linha enquanto o Rafael Espíndola, que trabalha com a gente, assumiu a linha mais acadêmica (além de me dar uma ajuda valiosa com alguns testes que requerem mais conhecimento técnico). Esse trabalho envolve a criação de um backend ARM para o LLVM e posteriormente melhorar o backend LLVM do PyPy para que com essas duas ferramentas seja possível gerar código binário nativo para ARM a partir de código fonte Python.
Como o maior problema de performance do CPython no 770 era relacionado ao carregamento de módulos resolvi atacá-lo primeiro e para atacá-lo fui entender como ele funcionava. Não gostei muito do que vi.
Aparentemente o sistema de ‘import’ do Python nunca recebeu uma atenção muito grande e desde o começo ele vem recebendo patches em cima de patches. Muitas funcionalidades foram adicionadas sem muito planejamento ou, por manter compatibilidade retroativa, tiveram implementações pouco elegantes.
Decidi então fazer uma reforma nesse sistema tentando deixá-lo mais elegante e ao mesmo tempo não tentar quebrar compatibilidade retroativa gratuitamente.
Como estou interessado nessa parte do desenvolvimento do CPython eu me ofereci para ajudar o Brett Canon em uma das tarefas propostas para o Python Google Sprint. Infelizmente o Brett tinha outras prioridades para esse Sprint e pode se oferecer apenas para me ajudar quando eu precisasse. O Guido, por sua vez, também pediu para eu adicionar meu nome na tarefa.
Durante o período do Sprint eu desenvolvi um esboço (bem inicial e incompleto) do que eu planejava para que eles pudessem entender que rumo eu gostaria de seguir.
Mostrei o meu trabalho para o Brett e ele me diz que o que ele planejava era algo bem mais simples que serviria já para o 2.6 e consistia apenas em reescrever a função __import__() em Python e que o meu plano era maior e certamente não seria aceito para a série 2.6.
Me apontou também a PEP-302 onde algumas das minhas idéias já foram discutidas e não foram aceitas (principalmente por adicionarem incompatibilidade retroativa). E disse que como os nossos planos eram muito diferente ele iria trabalhar nos planos dele mas que continuaria me ajudando se eu precisasse.
A sensação que eu tenho é a de que eu devo seguir adiante com esse plano meu nem que seja para facilitar o nosso trabalho no Python para Maemo. Depois que tudo estiver pronto e funcionando eu vou escrever uma PEP e submeter na lista python-3k.
Se for aceito, legal. Se não for, paciência. Só espero que eles entendam o que eu quero com esse projeto e não façam como fizeram com o Gustavo Niemeyer quando ele propôs a inclusão do dateutil na biblioteca padrão do Python (por não terem entendido a proposta do módulo optaram por miná-la ao invés de entendê-la).
3 Responses to “Python import”
Deixe um comentário
agosto 27th, 2006 at 1:28 pm
Olá, Osvaldo! Nos próximos episódios da saga, lembre-se de dizer quais são as idéias que você gostaria de ver implementadas, quais foram recusadas na PEP e quais ainda não sofreram adaptação. Não sei absolutamente nada dos métodos de importação do Python, e certamente não poderia ajudar muito, mas gostaria de ficar a par do que você está tentando fazer. Abraços!
agosto 27th, 2006 at 2:46 pm
Vamos ver se consigo resumir o que eu pretendo fazer:
1 - Atualmente sys.path é uma lista Python normal. Eu quero transformar sys.path em uma instância de um objeto que derive da lista de Python (que ficaria com a mesma interface da lista para evitar problema de compatibilidade) mas que sobrecarregue os métodos append / remove / insert para permitir que sempre que um path no formato string seja adicionado à ele essa string seja convertida em um objeto do tipo “ImportPath”.
2 - Um objeto ImportPath é um objeto que implementaria a mesma interface que str(), para também não quebrar compatibilidade. Um objeto do tipo ImportPath então requisitaria a todos os ImportPathHooks qual deles é capaz de importar módulos desse path. Esse objeto ImportPath, juntamente com o ImportPathHook poderia até mesmo popular um cache onde estariam listados todos os módulos disponíveis juntamente com onde eles podem ser encontrados.
3 - Quase todos os ImportPathHooks e quase todos (não pode ser todos) os ImportPaths default do Python seriam cadastrados no módulo site.py que por sua vez pode ter um mecanismo mais ‘inteligente’ para localizar módulos que implementem ImportPathHook’s.
4 - Criar um sistema de ModuleImportHook intercambiável que funcione de maneira análoga aos ImportPathHooks que permitiria que tivéssemos um ModuleImportHook para cada um dos seguintes casos: importar .py, importar .pyc, importar .pyo, importar .so/.dll/.???, importar módulos ‘freezados’, etc, etc.
5 - Implementar o máximo possível dessas funcionalidades em Python, deixando a parte em C somente para a execução de coisas mais básicas.
Coisas que seriam possíveis de serem feitas com esse sistema funcionando:
1 - colocar módulos em qualquer tipo de meio de armazenamento provendo em sua aplicação apenas um ImportPathHook para o sistema de import:
sys.path.append(”mysql!user,password,database”)
sys.path.append(”webservice!webservices.meuportal.com”)
2 - Como eu já disse, implementar cache de nome de módulos
3 - Compilar algumas extensões C Python diretamente junto à ele para evitar o uso de dlopen() (isso melhoraria a performance para importar o PyGTK no Maemo, por exemplo).
4 - Criar um hook ctypes, por exemplo, que consiga montar bindings para bibliotecas dinâmicas mais simples (ou que disponham de meta-dados sobre ela) simplesmente importando essa biblioteca diretamente (’on demand’).
5 - Quaisquer outras pirações imagináveis
Pode até ser que o meu desenho não seja bom para tais coisas, mas poder fazê-las seria muito massa.
agosto 27th, 2006 at 7:24 pm
Osvaldo,
Pelo o que eu entendi da sua idéia também seria possível desenvolver um import de módulos remotos (via HTTP por exemplo).
“A sensação que eu tenho é a de que eu devo seguir adiante com esse plano”
Apesar de não entender tudo que você quer, eu também tenho essa sensação.
Infelizmente não posso ajudar muito (falta de tempo e conhecimento), mas fica aqui o apoio moral.
Até mais.