Linguagem Python.

f_Candido
(usa Ubuntu)

Enviado em 18/09/2008 - 07:54h

Acredito que quando você o empacota como um executável, ele perde sim, sua portabilidade, pois estará visando uma única plataforma, mas também existem outras maneiras de resolver este problema(.pyc), lembrando que o Python é escrito em C, logo, seguindo o padrão ANSI, tudo se resolve.


Abraços

Teixeira
(usa Linux Mint)

Enviado em 18/09/2008 - 08:37h

Faz sentido.
Então seria efetivamente um compilador de Python, porém voltado exclusivamente para a plataforma Windows. Talvez tenha características de um emulador, ou coisa que o valha.

gjr_rj
(usa Debian)

Enviado em 18/09/2008 - 11:29h

Eu como uso windows(obrigado) e linux vou ver se consigo instalar e testar o python + py2exe esse final de semana e depois comento a experiência.

albfneto
(usa openSUSE)

Enviado em 18/09/2008 - 15:15h

Pelo que entendo das respostas, existe apenas um compilador, que compila Pyhon para exe, executável de Windows.
Quer dizer, em Linux, Python não é compilável, é apenas interpretável, é isso?

f_Candido
(usa Ubuntu)

Enviado em 18/09/2008 - 16:14h

Respondendo ao colega acima: Não, o Python é de qualquer forma compilado para um código intermediário, quase um byte code. Esse código intermediário, esse sim é interpretado.

Abraços

Teixeira
(usa Linux Mint)

Enviado em 18/09/2008 - 23:05h

Amigos,
Dei uma olhada rápida por aí e descobri três coisas:

1- A compilação de Python é para um código intermediário (ByteCode), sendo este então interpretado em tempo de execução, conforme o colega acima informou. Deve ser bem mais rápido que a execução direta pelo interpretador.

2- É possível "embutir" o interpretador junto com o programa, como eu suspeitava.

3- Também é possível mesclar os programas com trechos em C para aumentar a performance. Esse tipo de associação geralmente é muito poderosa, porém tem-se que conhecer também C (evidentemente) para que se possa obter esse super-benefício adicional.

gjr_rj
(usa Debian)

Enviado em 18/09/2008 - 23:38h

Teixeira,

você tem o link onde fala sobre embutir o interpretador no código ?
Eu não estou conseguindo entender como isso funciona.
Quando fala em colocar o interpretado e o código no mesmo arquivo, trata-se de um exe ?

Você entendeu como isso funciona?
O caso de compilar um código intermediário, até ai tudo bem. É +- como o java ou qualquer outro linguagem em que o criador deseja uma portabilidade, ou seja que rode sobre um interpretador e ao mesmo tempo queira que seja possível proteger o código, pois se deixar em texto, qualquer um pode entender e modificá-lo.

Mas o py2exe, o que ele faz na realidade ?

Teixeira
(usa Linux Mint)

Enviado em 19/09/2008 - 08:55h

Bem, na verdade eu não estou com tempo para fazer uma pesquisa mais profunda, poia até a próxima terça-feira estou "de cabeça" em um certo empreendimento.
(Vou ter de guardar minha curiosidade até lá).
Mas eu entrei no site oficial www.python.org e ali descobri um link para "languages: Portuguese-BR" onde tem mais alguma coisa, etc, e cheguei a uma certa palestra de um certo professor, porém sem maiores detalhes. As informações são exatamente tópicos da referida palestra.

OBS.: Parte dessa informação não está exatamente ali, mas o caminho foi esse mesmo.

gjr_rj
(usa Debian)

Enviado em 19/09/2008 - 11:17h

vlw Teixeira, como disse, final de semana vou dar uma olhada com mais calma neste assunto e posto caso encontre alguma novidade.

mslomp
(usa Slackware)

Enviado em 19/09/2008 - 13:14h

particularmente não conheço esse py2exe, mas segundo experiências anteriores, ele deve funcionar segundo o mesmo esquema que era utilizado em versões antigas do VB, ou seja, gera-se um p-code (pseudo code), que tem lá suas semelhanças com o bytecode utilizado pelo java, por exemplo. no caso do VB, quem realizava a "conversão", ou seja, executava o código nativo era uma dll (vbrunXX e, mais recentemente msvbvmXX. atualmente o trabalho sujo é feito pelo framework .net), sendo que esta possuía centenas e centenas de funções que interagiam de fato com as apis win32 - tanto é que aqueles tais de "declare function blablabla lib kernel32..." etc simplesmente informavam a essa máquina virtual que ao encontrar uma chamada a tal função, deveria executá-la e retornar os valores correspondentes. a grosso modo, essa máquina virtual era um pombo-correio entre o p-code e os recursos do windows.
na época havia um programa que embutia essa máquina virtual no executável gerado pelo vb, de modo que não era necessário que as dependências estivessem instaladas para executá-lo. muito intrigado que fiquei, resolvi investigar como aquilo era possível, e após diversas teorias, cheguei a uma solução que me parecia viável. fiz uns testes e bingo! é algo do tipo "claro, como não pensei nisso antes!!!"

então, chega de blablabla e vamos à "revelação" passo a passo de como a mágica funciona:
1 - criei uma dll nativa com o masm
2 - criei um projeto exe no vb (4 ou 5, não lembro) e adicionei suporte a resources
3 - embuti a tal dll como um resource binário
4 - no código vb, através das apis win32 para manipulação de resources (e não as funções nativas do vb para isso), eu extraía a dll para a memória como código executável
5 - estando ela em memória, eu podia mapeá-la e carregá-la através de LoadLibrary e então chamar suas funções normalmente

então eis que descobri que, no caso do programinha aquele, simplesmente havia um stub em código nativo que fazia esse serviço, visto que o p-code do executável vb só poderia funcionar após a vm estar carregada, lógico. então ele embutia tanto a vm quanto o exe gerado pelo vb.

sendo assim, talvez seja esse também o método utilizado por esse tal py2exe. a desvantagem é que sua vm traz junto muita coisa desnecessária, tornando o executável maior do que o que seria razoável. porém, isso pode ser contornado através de compactadores de executáveis, como o upx por exemplo.

dá para fazer isso num linux? a resposta é: sim, porém é necessária outra abordagem, visto que o elf não possui essa propriedade de resources, e também, não estamos lidando com dlls, e sim com pic (position independent code), apesar de que isso torna as coisas mais fáceis do que com dlls. a idéia básica seria embutir a vm sob formato shared object na seção de dados do executável, e através de artifícios (em assembly), mapeá-lo como porção de código (text).

ps: eu ainda devo possuir aquele meu projetinho em vb que mencionei acima. vou vasculhar o fundo do baú, e caso eu o encontre avisarei os colegas por aqui, e posso com prazer compartilhá-lo com os interessados.

rodolfomssouza
(usa Suse)

Enviado em 16/03/2011 - 20:25h

Como eu consigo fazer esse empacotamento do arquivo python no linux para rodar em um windows???