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.

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

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

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

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

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...

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?thre...>

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

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

O pr&oacute;prio Guido coloca de uma maneira bem honesta os pr&oacute;s, contras e desafios que ele encontrou imaginando esta altera&ccedil;&atilde;o na linguagem: <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=85551

E j&aacute; que que o artigo &eacute; de 2004, seria legal saber o que mudou na cabe&ccedil;a dele deste ent&atilde;o.

Uma op&ccedil;&atilde;o menos radical seria o uso do <a href="http://pychecker.sourceforge.net/

Tio, pára de reclamar:

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

Tio, p&aacute;ra de reclamar:

Quer Python com tipo declarado? Ent&atilde;o, toma.

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