E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é Ruby :P *Boo é Boo* -- 'Cê 'táva certo Juan...
> Este é pra lembrar que "as aparências enganam"...
> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez > tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é > Ruby :P > *Boo é Boo* -- 'Cê 'táva certo Juan...
Gostei da idéia de postar esse tipo de coisa no blog ao invés de transformar em um e-mail que vai ficar só aqui na lista e que, mesmo aqui, muita gente vai simplesmente ignorar por causa do tamanho.
> Transfomei um comentário que faria aqui em um post: > http://blog.rodolfocarvalho.net/2011/05/boo-nao-e-python.html > Este é pra lembrar que "as aparências enganam"... > E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez > tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é > Ruby :P > Boo é Boo -- 'Cê 'táva certo Juan...
Interessante o post muito bom, estava dando uma olhada em boo em conjunto com a unity3D, sim é bem parecido com python e linguagens modernas, mas, nota-se claramente que uma coisa é uma coisa e outra coisa é a outra coisa mesmo!!!
=D
confusão resolvida graças ao post =D
Em 26 de maio de 2011 21:36, Flávio Amieiro <flavioamie...@gmail.com>escreveu:
> Gostei da idéia de postar esse tipo de coisa no blog ao invés de > transformar em um e-mail que vai ficar só aqui na lista e que, mesmo > aqui, muita gente vai simplesmente ignorar por causa do tamanho.
> 2011/5/26 Rodolfo Carvalho <rhcarva...@gmail.com>: > > Transfomei um comentário que faria aqui em um post: > > http://blog.rodolfocarvalho.net/2011/05/boo-nao-e-python.html > > Este é pra lembrar que "as aparências enganam"... > > E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez > > tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é > > Ruby :P > > Boo é Boo -- 'Cê 'táva certo Juan...
__init__ é disparado pelo "=" em seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
assim como o __add__ é disparado pelo "+" em seu_obj + seu_outro_obj
ou o __getitem__ é disparado pelos [] em seu_obj[uma_chave]
ou o __hash__ de certa forma da mesma forma pelo [] em qq_dic[seu_obj]
ou o __getattr__ pelo "." em seu_obj.qq_atributo
ou o __nonzero__ por qualquer teste booleano como em if seu_obj:
ou o __repr__ para que o seu objeto se represente quando você simplesmente seu_obj
ou o __str__ quando você quer print seu_obj
ou o __call__ para os "()" ou tornar o seu objeto "chamável" seu_obj()
...
consistente. __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão para todo e qualquer objeto Python, builtin ou criado por você. ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde um protocolo que pode ser implementado ou sobrescrito. e serão sempre os __whatever__ ...
>> Este é pra lembrar que "as aparências enganam"...
>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez >> tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é >> Ruby :P >> *Boo é Boo* -- 'Cê 'táva certo Juan...
__init__ => constructor __add__ => op_Add __getitem__ => Em boo, os índices são aplicados em propriedades, não em objetos. Então basta declarar uma propriedade com parâmetros (como se fosse um método). __nonzero__ => op_True __repr__ => sem equivalente __str__ => ToString __call__ => sem equivalente
> __init__ é disparado pelo "=" em > seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
> assim como o __add__ é disparado pelo "+" em > seu_obj + seu_outro_obj
> ou o __getitem__ é disparado pelos [] em > seu_obj[uma_chave]
> ou o __hash__ de certa forma da mesma forma pelo [] em > qq_dic[seu_obj]
> ou o __getattr__ pelo "." em > seu_obj.qq_atributo
> ou o __nonzero__ por qualquer teste booleano como em > if seu_obj:
> ou o __repr__ para que o seu objeto se represente quando você simplesmente > seu_obj
> ou o __str__ quando você quer > print seu_obj
> ou o __call__ para os "()" ou tornar o seu objeto "chamável" > seu_obj()
> ...
> consistente. > __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão > para todo e qualquer objeto Python, builtin ou criado por você. > ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde um > protocolo que pode ser implementado ou sobrescrito. e serão sempre os > __whatever__ ...
>>> Este é pra lembrar que "as aparências enganam"...
>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez >>> tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é >>> Ruby :P >>> *Boo é Boo* -- 'Cê 'táva certo Juan...
> __init__ => constructor > __add__ => op_Add > __getitem__ => Em boo, os índices são aplicados em propriedades, não em > objetos. Então basta declarar uma propriedade com parâmetros (como se fosse > um método). > __nonzero__ => op_True > __repr__ => sem equivalente > __str__ => ToString > __call__ => sem equivalente
>> __init__ é disparado pelo "=" em >> seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
>> assim como o __add__ é disparado pelo "+" em >> seu_obj + seu_outro_obj
>> ou o __getitem__ é disparado pelos [] em >> seu_obj[uma_chave]
>> ou o __hash__ de certa forma da mesma forma pelo [] em >> qq_dic[seu_obj]
>> ou o __getattr__ pelo "." em >> seu_obj.qq_atributo
>> ou o __nonzero__ por qualquer teste booleano como em >> if seu_obj:
>> ou o __repr__ para que o seu objeto se represente quando você simplesmente >> seu_obj
>> ou o __str__ quando você quer >> print seu_obj
>> ou o __call__ para os "()" ou tornar o seu objeto "chamável" >> seu_obj()
>> ...
>> consistente. >> __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão >> para todo e qualquer objeto Python, builtin ou criado por você. >> ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde um >> protocolo que pode ser implementado ou sobrescrito. e serão sempre os >> __whatever__ ...
>>>> Este é pra lembrar que "as aparências enganam"...
>>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez >>>> tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é >>>> Ruby :P >>>> *Boo é Boo* -- 'Cê 'táva certo Juan...
> Este é pra lembrar que "as aparências enganam"...
> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez > tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é > Ruby :P > *Boo é Boo* -- 'Cê 'táva certo Juan...
2011/5/27 Jonatas Emidio de Souza <jonatasemi...@gmail.com>
> Salve Rodolfo!!!
> Grafia correta!! poucos acertam.
Que bom que minha memória não falhou!
> Li o post e achei show de bola! > Deixei lá o meu comentario.
Obrigado.
> (Boo é Boo - O fato de eu utilizar e gostar de python me deixou bem > bitolado).
Taí um ponto que temos em comum, também utilizo e gosto muito de Python :D Mas acho que a segunda parte não se aplica muito, procuro abrir a mente para outras linguagens. A bola da vez é o Racket :D Além das muitas coisas que se aprende ao entender programação funcional e Lisp (não necessariamente interligados), o ambiente criado ao redor do Racket é fantástico, da mais alta qualidade.
Eu tinha mais um email longo como resposta, então botei em prática minha auto-promessa de postar mais no blog, para quem sabe exportar o conhecimento que fazemos circular aqui para outros cantos.
Fiz uma reflexão das consequências de termos "__init__" ou "contructor" nas nossas linguagens (imagine-se criando a sua própria daqui a um tempo...):
>> __init__ => constructor >> __add__ => op_Add >> __getitem__ => Em boo, os índices são aplicados em propriedades, não em >> objetos. Então basta declarar uma propriedade com parâmetros (como se fosse >> um método). >> __nonzero__ => op_True >> __repr__ => sem equivalente >> __str__ => ToString >> __call__ => sem equivalente
>>> __init__ é disparado pelo "=" em >>> seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
>>> assim como o __add__ é disparado pelo "+" em >>> seu_obj + seu_outro_obj
>>> ou o __getitem__ é disparado pelos [] em >>> seu_obj[uma_chave]
>>> ou o __hash__ de certa forma da mesma forma pelo [] em >>> qq_dic[seu_obj]
>>> ou o __getattr__ pelo "." em >>> seu_obj.qq_atributo
>>> ou o __nonzero__ por qualquer teste booleano como em >>> if seu_obj:
>>> ou o __repr__ para que o seu objeto se represente quando você >>> simplesmente >>> seu_obj
>>> ou o __str__ quando você quer >>> print seu_obj
>>> ou o __call__ para os "()" ou tornar o seu objeto "chamável" >>> seu_obj()
>>> ...
>>> consistente. >>> __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão >>> para todo e qualquer objeto Python, builtin ou criado por você. >>> ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde um >>> protocolo que pode ser implementado ou sobrescrito. e serão sempre os >>> __whatever__ ...
>>>>> Este é pra lembrar que "as aparências enganam"...
>>>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez >>>>> tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é >>>>> Ruby :P >>>>> *Boo é Boo* -- 'Cê 'táva certo Juan...
Entendo a importância dos protocolos defindos com os "__whatever__". Não nego. Só acho que deveria existir algum açucar sintático para o "__init__". De qualquer forma, os equivalentes em Boo no post acima são, na verdade, definidos pelo próprio .NET.
Em .NET, todo objeto tem pelo menos 4 métodos: Equals, GetHashCode, GetType e ToString. Eles são métodos usados pelo framework para diversas tarefas. Tirando isso, o resto é definido por operadores. O fato dos métodos se chamarem op_Add, op_Subtract, etc., é uma convenção do .NET e não das linguagens. Em C# existe açucar para isso.
operator +(Tipo a, Tipo b) { ... }
Quanto a protocolos próprios, ainda prefiro a elegância de interfaces para isso. Duck typing é mais uma ferramenta do que uma filosofia para quem é fã de tipagem estática.
> Eu tinha mais um email longo como resposta, então botei em prática minha > auto-promessa de postar mais no blog, para quem sabe exportar o conhecimento > que fazemos circular aqui para outros cantos.
> Fiz uma reflexão das consequências de termos "__init__" ou "contructor" nas > nossas linguagens (imagine-se criando a sua própria daqui a um tempo...):
>>> __init__ => constructor >>> __add__ => op_Add >>> __getitem__ => Em boo, os índices são aplicados em propriedades, não em >>> objetos. Então basta declarar uma propriedade com parâmetros (como se fosse >>> um método). >>> __nonzero__ => op_True >>> __repr__ => sem equivalente >>> __str__ => ToString >>> __call__ => sem equivalente
>>>> __init__ é disparado pelo "=" em >>>> seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
>>>> assim como o __add__ é disparado pelo "+" em >>>> seu_obj + seu_outro_obj
>>>> ou o __getitem__ é disparado pelos [] em >>>> seu_obj[uma_chave]
>>>> ou o __hash__ de certa forma da mesma forma pelo [] em >>>> qq_dic[seu_obj]
>>>> ou o __getattr__ pelo "." em >>>> seu_obj.qq_atributo
>>>> ou o __nonzero__ por qualquer teste booleano como em >>>> if seu_obj:
>>>> ou o __repr__ para que o seu objeto se represente quando você >>>> simplesmente >>>> seu_obj
>>>> ou o __str__ quando você quer >>>> print seu_obj
>>>> ou o __call__ para os "()" ou tornar o seu objeto "chamável" >>>> seu_obj()
>>>> ...
>>>> consistente. >>>> __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão >>>> para todo e qualquer objeto Python, builtin ou criado por você. >>>> ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde >>>> um protocolo que pode ser implementado ou sobrescrito. e serão sempre os >>>> __whatever__ ...
>>>>>> Este é pra lembrar que "as aparências enganam"...
>>>>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que >>>>>> talvez tenha ficado meio perdido... Boo não é Python, não é Iron Python, e >>>>>> nem é Ruby :P >>>>>> *Boo é Boo* -- 'Cê 'táva certo Juan...
> Entendo a importância dos protocolos defindos com os "__whatever__". Não > nego. Só acho que deveria existir algum açucar sintático para o "__init__". > De qualquer forma, os equivalentes em Boo no post acima são, na verdade, > definidos pelo próprio .NET.
> Em .NET, todo objeto tem pelo menos 4 métodos: Equals, GetHashCode, GetType > e ToString. Eles são métodos usados pelo framework para diversas tarefas. > Tirando isso, o resto é definido por operadores. O fato dos métodos se > chamarem op_Add, op_Subtract, etc., é uma convenção do .NET e não das > linguagens.
Faz sentido que fosse... Por exemplo, em outra plataforma, Clojure é Lisp mas acaba herdando várias coisas de Java por conta de rodar na JVM e ser bastante integrado com a linguagem Java.
> Em C# existe açucar para isso.
> operator +(Tipo a, Tipo b) { ... }
Vemos aí mais uma das "escolhas"... o quão "diabética" é a linguagem :D
> Quanto a protocolos próprios, ainda prefiro a elegância de interfaces para > isso. Duck typing é mais uma ferramenta do que uma filosofia para quem é fã > de tipagem estática.
é como você disse, em Python há um padrão visivelmente* (literalmente) bem definido ;-)
* é, basta olhar para o texto :D
nintendi o __getitem__ ... em Python ele faz parte do protocolo de conteineres dicionários like. ou, pra fazer o seu objeto se comportar como um dicionário... ou responder ao protocolo de dicts... eu ainda acho que eu estou ganhando :D ... o protocolo parece ortogonal, completo e bem definido em Python, independente da aparência e custo da digitação dos __ __ ...
>> __init__ => constructor >> __add__ => op_Add >> __getitem__ => Em boo, os índices são aplicados em propriedades, não em >> objetos. Então basta declarar uma propriedade com parâmetros (como se fosse >> um método). >> __nonzero__ => op_True >> __repr__ => sem equivalente >> __str__ => ToString >> __call__ => sem equivalente
>>> __init__ é disparado pelo "=" em >>> seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
>>> assim como o __add__ é disparado pelo "+" em >>> seu_obj + seu_outro_obj
>>> ou o __getitem__ é disparado pelos [] em >>> seu_obj[uma_chave]
>>> ou o __hash__ de certa forma da mesma forma pelo [] em >>> qq_dic[seu_obj]
>>> ou o __getattr__ pelo "." em >>> seu_obj.qq_atributo
>>> ou o __nonzero__ por qualquer teste booleano como em >>> if seu_obj:
>>> ou o __repr__ para que o seu objeto se represente quando você >>> simplesmente >>> seu_obj
>>> ou o __str__ quando você quer >>> print seu_obj
>>> ou o __call__ para os "()" ou tornar o seu objeto "chamável" >>> seu_obj()
>>> ...
>>> consistente. >>> __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão >>> para todo e qualquer objeto Python, builtin ou criado por você. >>> ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde um >>> protocolo que pode ser implementado ou sobrescrito. e serão sempre os >>> __whatever__ ...
>>>>> Este é pra lembrar que "as aparências enganam"...
>>>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez >>>>> tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é >>>>> Ruby :P >>>>> *Boo é Boo* -- 'Cê 'táva certo Juan...
> é como você disse, em Python há um padrão visivelmente* (literalmente) bem > definido ;-)
> * é, basta olhar para o texto :D
> nintendi o __getitem__ ... em Python ele faz parte do protocolo de > conteineres dicionários like. ou, pra fazer o seu objeto se comportar como > um dicionário... ou responder ao protocolo de dicts... > eu ainda acho que eu estou ganhando :D ... o protocolo parece ortogonal, > completo e bem definido em Python, independente da aparência e custo da > digitação dos __ __ ...
>>> __init__ => constructor >>> __add__ => op_Add >>> __getitem__ => Em boo, os índices são aplicados em propriedades, não em >>> objetos. Então basta declarar uma propriedade com parâmetros (como se fosse >>> um método). >>> __nonzero__ => op_True >>> __repr__ => sem equivalente >>> __str__ => ToString >>> __call__ => sem equivalente
>>>> __init__ é disparado pelo "=" em >>>> seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
>>>> assim como o __add__ é disparado pelo "+" em >>>> seu_obj + seu_outro_obj
>>>> ou o __getitem__ é disparado pelos [] em >>>> seu_obj[uma_chave]
>>>> ou o __hash__ de certa forma da mesma forma pelo [] em >>>> qq_dic[seu_obj]
>>>> ou o __getattr__ pelo "." em >>>> seu_obj.qq_atributo
>>>> ou o __nonzero__ por qualquer teste booleano como em >>>> if seu_obj:
>>>> ou o __repr__ para que o seu objeto se represente quando você >>>> simplesmente >>>> seu_obj
>>>> ou o __str__ quando você quer >>>> print seu_obj
>>>> ou o __call__ para os "()" ou tornar o seu objeto "chamável" >>>> seu_obj()
>>>> ...
>>>> consistente. >>>> __whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão >>>> para todo e qualquer objeto Python, builtin ou criado por você. >>>> ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde >>>> um protocolo que pode ser implementado ou sobrescrito. e serão sempre os >>>> __whatever__ ...
>>>>>> Este é pra lembrar que "as aparências enganam"...
>>>>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que >>>>>> talvez tenha ficado meio perdido... Boo não é Python, não é Iron Python, e >>>>>> nem é Ruby :P >>>>>> *Boo é Boo* -- 'Cê 'táva certo Juan...
> No .NET, para fazer um objeto responder ao protocolo de dicionários, basta > implementar IDictionary<TKey, TValue><http://msdn.microsoft.com/en-us/library/s4ys34ea.aspx> (desculpe > linkar a MS nessa lista :P).
>> é como você disse, em Python há um padrão visivelmente* (literalmente) bem >> definido ;-)
>> * é, basta olhar para o texto :D
>> nintendi o __getitem__ ... em Python ele faz parte do protocolo de >> conteineres dicionários like. ou, pra fazer o seu objeto se comportar como >> um dicionário... ou responder ao protocolo de dicts... >> eu ainda acho que eu estou ganhando :D ... o protocolo parece ortogonal, >> completo e bem definido em Python, independente da aparência e custo da >> digitação dos __ __ ...
>>>> __init__ => constructor >>>> __add__ => op_Add >>>> __getitem__ => Em boo, os índices são aplicados em propriedades, não em >>>> objetos. Então basta declarar uma propriedade com parâmetros (como se fosse >>>> um método). >>>> __nonzero__ => op_True >>>> __repr__ => sem equivalente >>>> __str__ => ToString >>>> __call__ => sem equivalente
>>>>> __init__ é disparado pelo "=" em >>>>> seu_obj = SuaClasse() (ah! e tem o __new__ também, viu?)
>>>>> assim como o __add__ é disparado pelo "+" em >>>>> seu_obj + seu_outro_obj
>>>>> ou o __getitem__ é disparado pelos [] em >>>>> seu_obj[uma_chave]
>>>>> ou o __hash__ de certa forma da mesma forma pelo [] em >>>>> qq_dic[seu_obj]
>>>>> ou o __getattr__ pelo "." em >>>>> seu_obj.qq_atributo
>>>>> ou o __nonzero__ por qualquer teste booleano como em >>>>> if seu_obj:
>>>>> ou o __repr__ para que o seu objeto se represente quando você >>>>> simplesmente >>>>> seu_obj
>>>>> ou o __str__ quando você quer >>>>> print seu_obj
>>>>> ou o __call__ para os "()" ou tornar o seu objeto "chamável" >>>>> seu_obj()
>>>>> ...
>>>>> consistente. >>>>> __whatever__ remete ao protocolo (Javeiros chamariam "interface") >>>>> padrão para todo e qualquer objeto Python, builtin ou criado por você. >>>>> ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde >>>>> um protocolo que pode ser implementado ou sobrescrito. e serão sempre os >>>>> __whatever__ ...
>>>>>>> Este é pra lembrar que "as aparências enganam"...
>>>>>>> E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que >>>>>>> talvez tenha ficado meio perdido... Boo não é Python, não é Iron Python, e >>>>>>> nem é Ruby :P >>>>>>> *Boo é Boo* -- 'Cê 'táva certo Juan...
A classe que você quiser usar com a sintaxe nome[item] nem precisa ser verdadeiramente um *container*, pois sua implementação de __getitem__ pode fazer qualquer coisa.
Veja:
In [1]: import math
In [2]: math.pi Out[2]: 3.1415926535897931
In [3]: class Foo: ...: def __getitem__(self, item): ...: return math.pi ...:
In [4]: foo = Foo()
In [5]: foo["Quanto vale pi?"] Out[5]: 3.1415926535897931
In [6]: foo["Qual seu número favorito?"] Out[6]: 3.1415926535897931
In [7]: foo.__getitem__(42) Out[7]: 3.1415926535897931
> é como você disse, em Python há um padrão visivelmente* (literalmente) bem > definido ;-)
> * é, basta olhar para o texto :D
> nintendi o __getitem__ ... em Python ele faz parte do protocolo de > conteineres dicionários like. ou, pra fazer o seu objeto se comportar como > um dicionário... ou responder ao protocolo de dicts... > eu ainda acho que eu estou ganhando :D ... o protocolo parece ortogonal, > completo e bem definido em Python, independente da aparência e custo da > digitação dos __ __ ...
