Ensinando o Emacs a trabalhar com Python
Tales A. Mendonça (tales[arroba]linuxhard.org) enviou este link e acrescentou uma descrição telegráfica: Com algunas instalações e configurações podemos utilizar o emacs para programar em python.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Lucar
13/04/05 20:07 - usuário registrado #209
Python é realmente fantástico: Python é realmente fantástico, não sei porque as editoras nacionais não lançam e nem traduzem livros sobre python. Existe uma carência enorme de bons livros sobre essa linguagem em nosso idioma. É uma pena isso :(
Comentário de Ark
14/04/05 8:09
Talvez porque quem saiba Pyth: Talvez porque quem saiba Python seja muito arrogante pra achar que escrever um livro seja tarefa digna de um quase-deus.
E por isso que a gente já tem livros excelentes de Ruby, como há tempos tem de Java, etc.
Python vai acabar morrendo vítima da sua comunidade.
E por isso que a gente já tem livros excelentes de Ruby, como há tempos tem de Java, etc.
Python vai acabar morrendo vítima da sua comunidade.
Comentário de acidbase
14/04/05 14:53 - usuário registrado #113
Livro de Ruby?: Cadê o livro de Ruby em português? Sou simpático a Ruby e também acho uma pena não ter livros em português sobre essa fantástica linguagem (que tem como grande defensor o Guaracy Monteiro que é um cara realmente muito fera).
(Só uma informação: existe um livro em português-de-além-mar à venda na Tempo Real que é muito bom pra quem quer aprender Python)
Java tem livros em português porque teve (e tem) uma empresa bancando a comunidade com dinheiro à bastante tempo, enquanto a comunidade Python caminhou com as próprias pernas.
Com relação à arrogância da comunidade Python: Aparentemente só você tem esse problema. Afinal sempre que colocam uma notícia sobre Python aqui é só você que se manifesta dessa forma.
Deixo aqui a sugestão para os outros leitores do br-linux: que visitem o PythonBrasil e verifiquem por conta própria a nossa 'arrogância'. Lá no site existem instruções para participar da nossa lista de discussões (inclusive com as dicas de como obter respostas para as dúvidas mais comuns) e também de como participar da I PyConDayBrasil que vai ocorrer agora em Abril em Campinas onde alguns dos mais 'arrogantes' participantes da comunidade Python brasileira estarão.
--
Osvaldo Santana Neto (aCiDBaSe)
(Só uma informação: existe um livro em português-de-além-mar à venda na Tempo Real que é muito bom pra quem quer aprender Python)
Java tem livros em português porque teve (e tem) uma empresa bancando a comunidade com dinheiro à bastante tempo, enquanto a comunidade Python caminhou com as próprias pernas.
Com relação à arrogância da comunidade Python: Aparentemente só você tem esse problema. Afinal sempre que colocam uma notícia sobre Python aqui é só você que se manifesta dessa forma.
Deixo aqui a sugestão para os outros leitores do br-linux: que visitem o PythonBrasil e verifiquem por conta própria a nossa 'arrogância'. Lá no site existem instruções para participar da nossa lista de discussões (inclusive com as dicas de como obter respostas para as dúvidas mais comuns) e também de como participar da I PyConDayBrasil que vai ocorrer agora em Abril em Campinas onde alguns dos mais 'arrogantes' participantes da comunidade Python brasileira estarão.
--
Osvaldo Santana Neto (aCiDBaSe)
Comentário de Operador Nabla
14/04/05 18:58 - usuário registrado #1309
Tenho trabalhado intensamente: Tenho trabalhado intensamente com Python nestes últimos meses, bolando ferramentas para facilitar a minha vida de usuário do Gentoo Linux (e de sua ferramenta de instalação de pacotes, Portage, desenvolvida em Python). A impressão que eu tenho atualmente da linguagem é a seguinte: como linguagem script, Python é ESPETACULAR!, mas, como linguagem orientada a objetos, ainda deixa a desejar.
Eu utilizo o kit "Emacs + Pymacs + python-mode" para escrever os meus scripts e estou muito satisfeito.
Eu utilizo o kit "Emacs + Pymacs + python-mode" para escrever os meus scripts e estou muito satisfeito.
Comentário de acidbase
14/04/05 19:56 - usuário registrado #113
Porque?: Você poderia explicar porque que Python "como linguagem orientada a objetos deixa a desejar"? Ou isso é só uma opinião pessoal sem embasamento técnico?
--
Osvaldo Santana Neto (aCiDBaSe)
--
Osvaldo Santana Neto (aCiDBaSe)
Comentário de sou@chato.mesmo
15/04/05 0:37
Salada: Python é uma salada, o Van Rossum tomou umas pinga e montou um monstrengo.
A linguagem não possui terminador de comando, isso é um retrocesso!
Sou mais PHP, que possui uma sintaxe C like
A linguagem não possui terminador de comando, isso é um retrocesso!
Sou mais PHP, que possui uma sintaxe C like
Comentário de sou@chato.mesmo
15/04/05 0:43
Você queria o que ???: Pegaram um avestruz e socaram um estômago de elefante no coitado. A linguagem não foi projetada para ser OOP, é um interpretador extensível ao qual foram adicionando cada vez mais coisas, no final is a big mess.
E por design é uma linguagem lenta, mais lenta só Java
E por design é uma linguagem lenta, mais lenta só Java
Comentário de Operador Nabla
15/04/05 11:17 - usuário registrado #1309
Ok, ok, sejamos amenos... Ach: Ok, ok, sejamos amenos... Acho que eu fui um pouco exagerado em dizer que Python "deixa a desejar" como linguagem orientada a objetos. Então, se me permitirem, vou retirar momentaneamente o que disse e relatar, em seu lugar, algumas dificuldades que passei programando em Python (nem todas tem a ver com orientação a objetos):
- regular a visibilidade (pública, protegida, privada) de atributos e métodos de uma classe: ainda não descobri uma forma de se fazer isto em Python, nem sei se isto é possível no momento (o tutorial do Guido para Python 2.3 menciona que existe apenas um suporte "limitado" a atributos privados e dá uma pequena justificativa para esta questão ainda estar "em aberto"). Às vezes eu me pergunto se o fato de Python ser uma linguagem script dificulta a implementação de regras de visibilidade.
- declaração de métodos: muitos se queixam do inconveniente de incluir a própria classe, por meio da palavra reservada "self", como o primeiro argumento de um método de tal classe. A menos que haja uma boa justificativa para não fazê-lo, acho que a implementação da linguagem poderia ser modificada para que a inclusão do "self" como primeiro argumento seja implícita.
- funções anônimas: certa vez, enquanto eu escrevia um trecho de código Python, deparei-me com a necessidade de implementar uma função anônima um pouco mais complexa, mas não pude fazer isto porque, no momento, só é possível implementar funções anônimas de uma única linha em Python. Uma das características desta linguagem que mais me agradam é o suporte a alguns elementos típicos de programação funcional, como as funções anônimas e o mapeamento e redução de funções sobre listas. Por isso, espero que, num futuro bem próximo, o suporte a funções anônimas seja melhorado.
OBS: Tudo isso que eu disse refere-se à versão 2.3 da linguagem. Ainda não tive a oportunidade de experimentar a versão 2.4 para saber o que mudou.
PS: Não sei se aqui é um bom lugar para tirar dúvidas, mas gostaria de aproveitar a deixa para fazer uma pergunta.
Estou escrevendo um programa grande em Python e gostaria de quebrá-lo em vários arquivos, seguindo o modelo de aplicações Java (um arquivo para cada classe, todas as classes agrupadas em um pacote). Como você me sugere fazer isto? Também aceito indicações de fóruns e listas de discussão sobre Python.
- regular a visibilidade (pública, protegida, privada) de atributos e métodos de uma classe: ainda não descobri uma forma de se fazer isto em Python, nem sei se isto é possível no momento (o tutorial do Guido para Python 2.3 menciona que existe apenas um suporte "limitado" a atributos privados e dá uma pequena justificativa para esta questão ainda estar "em aberto"). Às vezes eu me pergunto se o fato de Python ser uma linguagem script dificulta a implementação de regras de visibilidade.
- declaração de métodos: muitos se queixam do inconveniente de incluir a própria classe, por meio da palavra reservada "self", como o primeiro argumento de um método de tal classe. A menos que haja uma boa justificativa para não fazê-lo, acho que a implementação da linguagem poderia ser modificada para que a inclusão do "self" como primeiro argumento seja implícita.
- funções anônimas: certa vez, enquanto eu escrevia um trecho de código Python, deparei-me com a necessidade de implementar uma função anônima um pouco mais complexa, mas não pude fazer isto porque, no momento, só é possível implementar funções anônimas de uma única linha em Python. Uma das características desta linguagem que mais me agradam é o suporte a alguns elementos típicos de programação funcional, como as funções anônimas e o mapeamento e redução de funções sobre listas. Por isso, espero que, num futuro bem próximo, o suporte a funções anônimas seja melhorado.
OBS: Tudo isso que eu disse refere-se à versão 2.3 da linguagem. Ainda não tive a oportunidade de experimentar a versão 2.4 para saber o que mudou.
PS: Não sei se aqui é um bom lugar para tirar dúvidas, mas gostaria de aproveitar a deixa para fazer uma pergunta.
Estou escrevendo um programa grande em Python e gostaria de quebrá-lo em vários arquivos, seguindo o modelo de aplicações Java (um arquivo para cada classe, todas as classes agrupadas em um pacote). Como você me sugere fazer isto? Também aceito indicações de fóruns e listas de discussão sobre Python.
Comentário de acidbase
15/04/05 12:05 - usuário registrado #113
Algumas respostas: - regular a visibilidade (pública, protegida, privada) de atributos e métodos de uma classe: ainda não descobri uma forma de se fazer isto em Python, nem sei se isto é possível no momento (o tutorial do Guido para Python 2.3 menciona que existe apenas um suporte "limitado" a atributos privados e dá uma pequena justificativa para esta questão ainda estar "em aberto"). Às vezes eu me pergunto se o fato de Python ser uma linguagem script dificulta a implementação de regras de visibilidade.
*Pessoalmente* acho desnecessário ajustes de visibilidades de interfaces mas para deixar um método ou atributo 'privado' basta prefixar o seu nome com '__'. Ainda sim o método/atributo poderá ser acessado mas será necessário um 'malabarismo' maior.
Com o surgimento das properties em Python tornar um atributo privado tornou-se mais desnecessário ainda já que você poderia fazer coisas como: objeto.atributo = "foo" sem maiores problemas (o Python 'converteria' isso para: objeto.setAtributo("foo") de forma transparente).
- declaração de métodos: muitos se queixam do inconveniente de incluir a própria classe, por meio da palavra reservada "self", como o primeiro argumento de um método de tal classe. A menos que haja uma boa justificativa para não fazê-lo, acho que a implementação da linguagem poderia ser modificada para que a inclusão do "self" como primeiro argumento seja implícita.
O Gustavo Niemeyer tem uma boa para essa: se o que vc tem para reclamar de Python é 'só isso' significa que Python é muito boa :)
Eu acho isso chato também mas não me incomoda muito. Eu prefiro acertar meu editor de textos para escrever 'self, ' automaticamente pra mim :)
Existe uma 'lenda' que diz que o self está ali porque 'Explicity is better than implicity' mas eu não acredito nela e acho que foi apenas uma escolha de projeto que depois não pôde ser 'consertada'.
- funções anônimas: certa vez, enquanto eu escrevia um trecho de código Python, deparei-me com a necessidade de implementar uma função anônima um pouco mais complexa, mas não pude fazer isto porque, no momento, só é possível implementar funções anônimas de uma única linha em Python. Uma das características desta linguagem que mais me agradam é o suporte a alguns elementos típicos de programação funcional, como as funções anônimas e o mapeamento e redução de funções sobre listas. Por isso, espero que, num futuro bem próximo, o suporte a funções anônimas seja melhorado.
Eu tenho uma notícia triste e uma boa pra te dar: tudo indica que as 'lambdas' morrerão no Python3000 :/ Não sei se gosto ou desgosto dessa decisão. De qualquer forma ela ainda não foi tomada.
Mas tenho que dizer que funções anônimas devem simplesmente avaliar expressões e não conter lógica ou statements. para isso você pode definir uma função convencional que, em Python, também são funções 'callable' assim como as lambdas.
Estou escrevendo um programa grande em Python e gostaria de quebrá-lo em vários arquivos, seguindo o modelo de aplicações Java (um arquivo para cada classe, todas as classes agrupadas em um pacote). Como você me sugere fazer isto? Também aceito indicações de fóruns e listas de discussão sobre Python.
Aqui não é exatamente o melhor lugar para responder isso. Recomendo que essa pergunta vá lá para a lista python-brasil (pythonbrasil.com.br tem instruções para entrar na lista que fica no Yahoo! Grupos). Mas vou explicar como você deverá proceder de forma suscinta:
Se você colocar um arquivo "__init__.py" dentro de um diretório no PYTHONPATH esse diretório se torna um package. Funciona de forma ligeiramente diferente do Java mas lhe servirá da mesma forma.
--
Osvaldo Santana Neto (aCiDBaSe)
*Pessoalmente* acho desnecessário ajustes de visibilidades de interfaces mas para deixar um método ou atributo 'privado' basta prefixar o seu nome com '__'. Ainda sim o método/atributo poderá ser acessado mas será necessário um 'malabarismo' maior.
Com o surgimento das properties em Python tornar um atributo privado tornou-se mais desnecessário ainda já que você poderia fazer coisas como: objeto.atributo = "foo" sem maiores problemas (o Python 'converteria' isso para: objeto.setAtributo("foo") de forma transparente).
- declaração de métodos: muitos se queixam do inconveniente de incluir a própria classe, por meio da palavra reservada "self", como o primeiro argumento de um método de tal classe. A menos que haja uma boa justificativa para não fazê-lo, acho que a implementação da linguagem poderia ser modificada para que a inclusão do "self" como primeiro argumento seja implícita.
O Gustavo Niemeyer tem uma boa para essa: se o que vc tem para reclamar de Python é 'só isso' significa que Python é muito boa :)
Eu acho isso chato também mas não me incomoda muito. Eu prefiro acertar meu editor de textos para escrever 'self, ' automaticamente pra mim :)
Existe uma 'lenda' que diz que o self está ali porque 'Explicity is better than implicity' mas eu não acredito nela e acho que foi apenas uma escolha de projeto que depois não pôde ser 'consertada'.
- funções anônimas: certa vez, enquanto eu escrevia um trecho de código Python, deparei-me com a necessidade de implementar uma função anônima um pouco mais complexa, mas não pude fazer isto porque, no momento, só é possível implementar funções anônimas de uma única linha em Python. Uma das características desta linguagem que mais me agradam é o suporte a alguns elementos típicos de programação funcional, como as funções anônimas e o mapeamento e redução de funções sobre listas. Por isso, espero que, num futuro bem próximo, o suporte a funções anônimas seja melhorado.
Eu tenho uma notícia triste e uma boa pra te dar: tudo indica que as 'lambdas' morrerão no Python3000 :/ Não sei se gosto ou desgosto dessa decisão. De qualquer forma ela ainda não foi tomada.
Mas tenho que dizer que funções anônimas devem simplesmente avaliar expressões e não conter lógica ou statements. para isso você pode definir uma função convencional que, em Python, também são funções 'callable' assim como as lambdas.
Estou escrevendo um programa grande em Python e gostaria de quebrá-lo em vários arquivos, seguindo o modelo de aplicações Java (um arquivo para cada classe, todas as classes agrupadas em um pacote). Como você me sugere fazer isto? Também aceito indicações de fóruns e listas de discussão sobre Python.
Aqui não é exatamente o melhor lugar para responder isso. Recomendo que essa pergunta vá lá para a lista python-brasil (pythonbrasil.com.br tem instruções para entrar na lista que fica no Yahoo! Grupos). Mas vou explicar como você deverá proceder de forma suscinta:
Se você colocar um arquivo "__init__.py" dentro de um diretório no PYTHONPATH esse diretório se torna um package. Funciona de forma ligeiramente diferente do Java mas lhe servirá da mesma forma.
--
Osvaldo Santana Neto (aCiDBaSe)