Passagem de Parâmetros em Python

May 26, 2009

Dentre os temas que geram discussões intermináveis, apaixonadas, e na maioria das vezes, completamente inúteis, a questão de tipagem de dados em linguagens de programação ocupa um espaço não desprezível.

Tipagem forte, tipagem fraca, tipagem estática, tipagem dinâmica. Existem prós e contras para cada lado, e os defensores de cada campo passam horas e horas tentando provar que o esquema alheio é péssimo. Tendo trabalhado com todos, programando em Java, Python, Javascript e C, chego à conclusão de que é possível ser feliz e produtivo com qualquer uma delas.

Mas nem tudo é perfeito, e em algumas situações, o jardim do vizinho é mais verde…

Sinto falta em alguns momentos de poder tipificar parâmetros de funções em Python, por dois motivos. O primeiro é para evitar que parâmetros de tipos errados sejam passados inadvertidamente: fazer verificação de tipo no início de um método ou função é simples, mas as vezes consome tempo de programação inútil.

O outro que mais me incomoda é que a falta desta tipagem impede que se utilize um recurso muito útil e elegante que é a sobrecarga de método. Basicamente, em Python não é possível criar vários métodos com o mesmo nome e com assinaturas diferentes. O jeito Python de resolver isso é verificando o tipo dentro do método, ou então criando um mecanismo de dispatch, usando os famosos dicionários (que são extremamente eficientes. Ousam dizer por aí que é a implementação mais eficiente que existe….).

Ambas funcionam, mas não são tão elegantes como a solução oferecida pela sobrecarga. Aproveito, pergunto: existe alguma forma mais elegante de se fazer isso em Python?

Fica aqui a minha sugestão. HEY, GUIDO, TIPIFICA OPCIONALMENTE PARÂMETRO DE MÉTODO AÍ!

tags: , , ,
posted in Desenvolvimento, Design by Miguel Galves

Follow comments via the RSS Feed | Leave a comment | Trackback URL

View Comments to "Passagem de Parâmetros em Python"

  1. Thiago Bartolomei wrote:

    Eu gosto de tipos. Eu programo a maioria do tempo em Java e quando programo em Ruby eu sinto falta, principalmente pra entender código alheio (ou antigo) ou, como você disse, quando quero sobrecarregar um método. O que acabo fazendo é um método com vários parâmetros opcionais, o que fica bem feio.

    Mas Java é um exagero. Cada vez que eu faco algo como:

    String s = "Uma String";

    ou

    List<Integer> list = new ArrayList<Integer>();


    eu me irrito profundamente. É óbvio que s é uma String. E pra que escrever 2 vezes “Integer”?

    Está na minha lista de TODO aprender Scala. Pelo pouco que vi, eles tem tipagem estática como Java, mas o compilador tenta ao máximo inferir os tipos que você não escreve. Nesse caso, por exemplo, não precisaria avisar que s é uma String, e é óbvio que a ArrayList é de Integer, então imagino que você não precisaria escrever (não sei Scala, então não sei se type inference funciona com generics, mas eu acredito que sim). Quando por algum motivo o compilador não consegue inferir o tipo, ele reclama e pede pra você dar mais informações.

    Me parece ser um bom trade-off, pois o código fica mais limpo e ainda assim é totalmente tipado estaticamente.

    Outra linguagem interessante é aquela Duby, do mesmo cara que mantém o JRuby. A idéia é fazer uma linguagem com gosto de Ruby mas que seja eficiente na JVM (já que Ruby tem algumas features que fazem com que o bytecode gerado seja muito defensivo, atrapalhando a performance). Eles também tem type inference como Scala. Pena que não fizeram nenhuma release ainda…

    []s Bart

    Links:

    Intro to Scala Type Inference

    http://www.scala-lang.org/node/127

    Duby Language

    http://kenai.com/projects/duby/pages/Home

  2. Raphael Lullis wrote:

    Tio, pára de reclamar:

    Quer Python com tipo declarado? Então, toma.

  3. Bruno wrote:

    Uma opção menos radical seria o uso do http://pychecker.sourceforge.net/

  4. Bruno wrote:

    O próprio Guido coloca de uma maneira bem honesta os prós, contras e desafios que ele encontrou imaginando esta alteração na linguagem: http://www.artima.com/weblogs/viewpost.jsp?thread=85551

    E já que que o artigo é de 2004, seria legal saber o que mudou na cabeça dele deste então.

  5. Bruno wrote:

    E olha que interessante, GvR sugere o uso de decorators para criar automaticamente o código para as tais dispach tables que o Miguel citou:

    The overloaded decorator could build a multimethod dispatched based on the call signature. That’s probably quicker than decoding the types by hand from a varargs argument…

  6. Tarantula wrote:

    Trabalho com Python já há mais de 5 anos e nunca senti falta de tipagem estática.

  7. Bruno wrote:

    Bom, o próprio GvR considerou seriamente a possibilidade adicinar a declaração de tipos, de uma maneira opcional… isto diz muita coisa.

  8. Henrique wrote:

    Sobrecarga de métodos é uma muleta para as limitações da tipagem estática, onde você reescreve o mesmo método várias vezes para acomodar novos tipos. Em tipagem dinamica, aprenda a usar Duck Typying.

    def aceitafilelike(stream): if hasattr(stream, ‘write’) and hasattr(stream, ‘close’): stream.write(‘Teste’) return stream.close() else: raise ValueError

    Vai aceitar qualquer objeto File ou que implemente a mesma interface, e vai continuar funcionando para objetos de outros tipos que voce ainda nem conhecia quando implementou isso.

    E mais uma questao de aprender a pensar diferente com linguagens dinamicas.

Leave Your Comment

blog comments powered by Disqus

Switch to our mobile site

 
Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org