[python-brasil] Serviço de números por extenso no Google App Engine
Luciano Ramalho
dado um número entre 0 e 999999999999999 (10**14-1), devolve o número
escrito por extenso em português do Brasil (em Portugal há grandes
diferenças a partir dos bilhões).
Para testar o serviço, você precisa passar o número como parâmetro n
na URL, assim:
http://labtmpbr.appspot.com/extenso?n=987654321
o resultado no caso é:
novecentos e oitenta e sete milhões, seiscentos e cinquenta e quatro
mil, trezentos e vinte e um
Este código é um pequeno exemplo de como colocar no ar uma aplicação
muito simples no AppEngine. Pode ser útil para quem está iniciando no
uso da plataforma do Google.
O código está todo online, no meu repositório de exemplos Propython:
http://code.google.com/p/propython/source/browse/appengine/labtmpbr/extenso.py
(veja também os demais arquivos no diretório labtmpbr, que formam o
resto de uma aplicação muito básica no AppEngine)
Agora estou saindo para ir ao cinema, então vou deixar uma questão
aberta aqui: olhando o código do extenso.py vc vai notar que na função
cardinal() existe um assert que limita o número a ser convertido.
Coloquei aquele assert lá porque quando testei com 9999999999999999
(10**15-1) esbarrei no limite de recursão do Python. Lá no código, no
final dos testes, tem reproduzida a exceção que eu obtive, e parte do
traceback.
Não consegui entender até agora porque acontece aquele erro. Sim, a
minha implementação é recursiva, mas não entendi onde a coisa está
quebrando...
Sobre os jeito de escrever os números, achei esta ref:
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
------------------------------------
Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/python-brasil/
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Leandro Lameiro
> Implementei uma app no Google App Engine que faz apenas um serviço:
> dado um número entre 0 e 999999999999999 (10**14-1), devolve o número
> escrito por extenso em português do Brasil (em Portugal há grandes
> diferenças a partir dos bilhões).
>
>
> aberta aqui: olhando o código do extenso.py vc vai notar que na função
> cardinal() existe um assert que limita o número a ser convertido.
> Coloquei aquele assert lá porque quando testei com 9999999999999999
> (10**15-1) esbarrei no limite de recursão do Python. Lá no código, no
> final dos testes, tem reproduzida a exceção que eu obtive, e parte do
> traceback.
>
> Não consegui entender até agora porque acontece aquele erro. Sim, a
> minha implementação é recursiva, mas não entendi onde a coisa está
> quebrando...
Fala Ramalho,
Quando você passa esse 999999999999999 seu algoritmo recursivo não faz
nada na chamada-mãe (cabeca = 0) e deixa todo o trabalho pra
chamada-filha, e a filha para a neta, e assim infinitamente. Em outras
palavras, o divide-and-conquer não está dividindo nada.
O problema aqui é a precisão do log. Neste caso, a chamada de
log(9999999999999999, 1000) retorna um 5.0 redondo, o que sabemos que
não é verdade, pois log(10**15, 1000) = 5.
Troque o log por ( (len(str(n))-1)/3 ) que tudo funciona.
--
Best regards,
Leandro Lameiro
Blog: http://lameiro.wordpress.com
Twitter: http://twitter.com/lameiro
Denis Costa
http://labtmpbr.appspot.com/extenso?=1
Denis Silva Costa
Ubuntu User: #31758
Linux User: #516577
"A paz não brota em um jardim com câmera e sensores..."
[As partes desta mensagem que não continham texto foram removidas]
Carlos Ribeiro
Uns 20 e poucos anos atrás, uma das primeiras coisas que eu fiz
profissionalmente, usando Turbo Pascal, foi uma rotina para imprimir cheques
com valores por extenso. Me lembro o quanto foi chato acertar todos os
casos. E achei o código do Luciano surpreendentemente simples, com
pouquíssimos "casos especiais" explícitos. O uso dos hashes ajudou muito,
mas mesmo assim fiquei curioso.
Assim, aproveitei o domingo de carnaval com chuva para experimentar um
pouco. Usei basicamente a mesma lógica, só que tentando tratar o número
sempre como "string" para eliminar o "log" e outros tratamentos do tipo. O
problema é que eliminar o "leading zero" de forma simples se mostrou mais
complicado do que eu imaginava... e o código acabou não ficando tão limpo. A
opção é aumentar a quantidade de tabelas de lookup, mas aí o código também
fica mais complicado. Ponto pro Luciano :-) (e para o Leandro que achou o
bug de recursão!!)
(No fim das contas, depois de muito penar, acertei praticamente tudo mas meu
código insiste em não colocar a vírgula corretamente no caso do milhar.
Lendo o código do Luciano não é trivial descobrir porque o dele funciona e
outros (ex: o meu) não funciona!)
Outra coisa curiosa que me passou pela cabeça foi imaginar se faz sentido
dispor desse tipo de função (simples de usar mas chatíssima de escrever)
como parte de uma biblioteca online. A idéia pode parecer meio maluca, é
muito overhead para pouca coisa - mas estou mais interessado no "princípio"
do que no caso específico. Faria sentido? O limite é apenas uma questão de
tempo - com a melhoria do acesso Internet, etc., esse tipo de técnica faria
mais sentido?
Carlos Ribeiro
2011/3/6 Leandro Lameiro <lam...@gmail.com>
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Carlos Ribeiro
http://labtmpbr.appspot.com/extenso?n=1
Carlos Ribeiro
2011/3/6 Denis Costa <denisc...@gmail.com>
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com
Luciano Ramalho
> Quando você passa esse 999999999999999 seu algoritmo recursivo não faz
> nada na chamada-mãe (cabeca = 0) e deixa todo o trabalho pra
> chamada-filha, e a filha para a neta, e assim infinitamente. Em outras
> palavras, o divide-and-conquer não está dividindo nada.
>
> O problema aqui é a precisão do log. Neste caso, a chamada de
> log(9999999999999999, 1000) retorna um 5.0 redondo, o que sabemos que
> não é verdade, pois log(10**15, 1000) = 5.
>
> Troque o log por ( (len(str(n))-1)/3 ) que tudo funciona.
Grande Lameiro, muito grato pela descoberta!
Eu tinha chegado a ver que cabeça virava zero naquele caso, mas ainda
não tinha sacado que o problema era na precisão do log.
Valeu!
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Luciano Ramalho
Oi, Denis, faltou colocar o parâmetro n. Experimente:
http://labtmpbr.appspot.com/extenso?n=1
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Luciano Ramalho
> 2011/3/6 Denis Costa <denisc...@gmail.com>:
>> Testei com um e deu zero
>>
>> http://labtmpbr.appspot.com/extenso?=1
>
> Oi, Denis, faltou colocar o parâmetro n. Experimente:
>
> http://labtmpbr.appspot.com/extenso?n=1
Estimulado pelas respostas e por duas xícaras de expresso, fiz alguns
aperfeiçoamentos no programa:
1) a API agora é RESTosa (RESTful): em vez de passar um parâmetro,
você acessa cada número como se ele fosse um recurso:
http://localhost:8080/extenso/1234567890987654321
devolve em text/plain, UTF-8:
um quintilhão, duzentos e trinta e quatro quadrilhões, quinhentos e
sessenta e sete trilhões, oitocentos e noventa bilhões, novecentos e
oitenta e sete milhões, seiscentos e cinquenta e quatro mil, trezentos
e vinte e um
2) ampliei o limite de números tratáveis até 10**63-1 (novecentos e
noventa e nove nonidecilhões etc...); o limite por enquanto foi dado
pelo dicionário Houaiss; não achei termos para números maiores em
fontes confiáveis, exceto pelo googol e derivados, que introduziriam
uma descontinuidade e complicariam o algoritmo, porque são muitas
ordens de grandeza maiores que 10**63
3) ainda no espírito do REST, caso o limite de 10**63-1 seja
ultrapassado na requisição, um código 400 (Bad Request) é devolvido,
com uma explicação no corpo da resposta; isso demonstra a manipulação
de cabeçalhos no framework WabApp do Google App Engine;
O código continua no mesmo repositório. O arquivo principal da aplicação é:
http://code.google.com/p/propython/source/browse/appengine/labtmpbr/main.py
Fica como exercício para os leitores adaptar o programa para a
nomenclatura européia, documentada aqui:
http://pt.wikipedia.org/wiki/Escalas_curta_e_longa
Agora posso dormir tranquilo, sabendo que vai levar alguns anos para
que a inflação torne este gerador de extenso obsoleto.
Valeu, pessoal!
Luciano Ramalho
> Assim, aproveitei o domingo de carnaval com chuva para experimentar um
> pouco. Usei basicamente a mesma lógica, só que tentando tratar o número
> sempre como "string" para eliminar o "log" e outros tratamentos do tipo. O
> problema é que eliminar o "leading zero" de forma simples se mostrou mais
> complicado do que eu imaginava... e o código acabou não ficando tão limpo. A
> opção é aumentar a quantidade de tabelas de lookup, mas aí o código também
> fica mais complicado. Ponto pro Luciano :-) (e para o Leandro que achou o
> bug de recursão!!)
>
> (No fim das contas, depois de muito penar, acertei praticamente tudo mas meu
> código insiste em não colocar a vírgula corretamente no caso do milhar.
> Lendo o código do Luciano não é trivial descobrir porque o dele funciona e
> outros (ex: o meu) não funciona!)
Oi, Carlos, com o Mercurial, pode ver a evolução do código fazendo um
checkout to meu reposotório propython e olhando os commits de ontem.
Coloquei comentários nos testes do próprio script marcando os
principais momentos de sua evolução. O melhor insight foi quando eu
percebi que era mais fácil separar o problema em duas partes que
cooperam: (1) gerar extensos de 0 a 999, e (2) gerar o extenso dos
milhares, milhões etc com o auxílio da primeira parte. Isso
simplificou muito, porque misturando as duas tarefas em um único
algoritmo recursivo eu tava ficando louco. A função cardinal999() por
sinal acho que ficou um bom exemplo didático de uso de recursão.
Eu também trabalhei bastante com Pascal no final dos anos 80. Era uma
ótima linguagem na época. Hoje eu me recuso a usar qualquer linguagem
que não tenha algo parecido com dicionários totalmente integrados, com
sintaxe nativa. Tem sido assim desde que eu troquei o Java pelo Perl,
semanas antes de descobrir o Python. O dicionário é a estrutura de
dados mais versátil que há. Com ela e listas, quase tudo se resolve.
Basta reparar que o modelo de dados do XML e do JSON são
essencialmente dicionários e listas.
> Outra coisa curiosa que me passou pela cabeça foi imaginar se faz sentido
> dispor desse tipo de função (simples de usar mas chatíssima de escrever)
> como parte de uma biblioteca online. A idéia pode parecer meio maluca, é
> muito overhead para pouca coisa - mas estou mais interessado no "princípio"
> do que no caso específico. Faria sentido? O limite é apenas uma questão de
> tempo - com a melhoria do acesso Internet, etc., esse tipo de técnica faria
> mais sentido?
Isso já está acontecendo. Tenho um amigo que trabalha no Registro.br e
lá eles têm um sistema muito bom para gerar boletos com código de
barra, etc. Um dia eles descobriram que a maior parte do tráfego que
tinha para o site deles era de usuários que geravam o código de barra
fazendo um GET para o Registro.br, simplesmente porque outros sites
montavam URLs dinâmicas em IMG para usar o "serviço de código de
barras" do Registro.br para gerar seus próprios boletos online! No
caso do Registro..br, não foi intencional, mas foi consequência de uma
arquitetura totalmente desacoplada. Acho que depois eles "fecharam a
porta" para usuários externos.
O Google oferece algo semelhante em sua Chart API, inclusive gerando
códigos 2D QCode:
http://code.google.com/intl/en/apis/chart/
Acho que a tendência é realmente que esse tipo de serviço seja cada
vez mais comum.
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Luciano Ramalho
> Só uma dúvida conceitual: não deveria ter uma vírgula (ou "e") entre
> "mil" e centenas, tal como existe entre "milhão" e centenas?
>
> cardinal(1101) => 'mil cento e um' mas não deveria ser 'mil, cento e um'
> (ou 'mil e cento e um') tal como ocorre com "milhão"?
> cardinal(1000101) => 'um milhão, cento e um'
Ou, Junior, deu trabalho implementar estas exceções! Pode ver que na
função cardinal() tem um lugar onde eu escolho entre os conectores '
', 'e' ou ','. Com base em quê? Como eu não sou gramático, com base no
que "soava bem" para mim.
A regra geral que eu adotei foi colocar vírgulas entre os blocos de
milhares, mas tem exceções na casa dos mil. Por exemplo, quando a
gente fala 1932 não tem uma pausa entre o "mil" e o "novecentos", por
isso eu não coloquei vírgula neste caso. Outra exceção é que antes das
centenas redondas vem um "e": mil e duzentos. O mesmo vale quando a
centena é zero: 1032 fica "mil e trinta e dois".
Junior Polegato - Linux
> Implementei uma app no Google App Engine que faz apenas um serviço:
> dado um número entre 0 e 999999999999999 (10**14-1), devolve o número
> escrito por extenso em português do Brasil (em Portugal há grandes
> diferenças a partir dos bilhões).
> Para testar o serviço, você precisa passar o número como parâmetro n
> na URL, assim:
> http://labtmpbr.appspot.com/extenso?n=987654321
> o resultado no caso é:
> novecentos e oitenta e sete milhões, seiscentos e cinquenta e quatro
> mil, trezentos e vinte e um
>
Legal, muito bom!
Só uma dúvida conceitual: não deveria ter uma vírgula (ou "e") entre
"mil" e centenas, tal como existe entre "milhão" e centenas?
cardinal(1101) => 'mil cento e um' mas não deveria ser 'mil, cento e um'
(ou 'mil e cento e um') tal como ocorre com "milhão"?
cardinal(1000101) => 'um milhão, cento e um'
[]'s
Junior Polegato
Junior Polegato - Linux
> 2011/3/7 Junior Polegato - Linux<li...@juniorpolegato.com.br>:
>
>> Só uma dúvida conceitual: não deveria ter uma vírgula (ou "e") entre
>> "mil" e centenas, tal como existe entre "milhão" e centenas?
>> cardinal(1101) => 'mil cento e um' mas não deveria ser 'mil, cento e um'
>> (ou 'mil e cento e um') tal como ocorre com "milhão"?
>> cardinal(1000101) => 'um milhão, cento e um'
>>
> Ou, Junior, deu trabalho implementar estas exceções! Pode ver que na
> função cardinal() tem um lugar onde eu escolho entre os conectores '
> ', 'e' ou ','. Com base em quê? Como eu não sou gramático, com base no
> que "soava bem" para mim.
> A regra geral que eu adotei foi colocar vírgulas entre os blocos de
> milhares, mas tem exceções na casa dos mil. Por exemplo, quando a
> gente fala 1932 não tem uma pausa entre o "mil" e o "novecentos", por
> isso eu não coloquei vírgula neste caso. Outra exceção é que antes das
> centenas redondas vem um "e": mil e duzentos. O mesmo vale quando a
> centena é zero: 1032 fica "mil e trinta e dois".
>
Olá!
Também não sou nenhum expert nisso, mas fui procurar e
encontrei essa página simples no estadão que pode ajudar, inclusive se
for estender aos ordinais:
http://www.estadao.com.br/manualredacao/esclareca/numerosporextenso.shtm
Por ela, não existe vírgula depois dos milhares, como no exemplo:
765.432.854.987 = setecentos e sessenta e cinco bilhões, quatrocentos e
trinta e dois milhões, oitocentos e cinqüenta e quatro mil novecentos e
oitenta e sete
Pelo seu:
765.432.854.987 = setecentos e sessenta e cinco bilhões, quatrocentos e
trinta e dois milhões, oitocentos e cinquenta e quatro mil, novecentos e
oitenta e sete
Então diferem pelo trema, que não existe mais na nova
ortografia, e a vírgula dos milhares, que você tem que tirar para ficar
conforme as regras.
Espero ter ajudado de alguma forma.
[]'s
Junior Polegato
Carlos Ribeiro
Tirei a dicussão da lista, porque achei que o pessoal poderia achar que
estava ficando offtopic. Se você achar razoável podemos voltar lá, para
discutir a parte técnica.
Você acha que a política do Google AppEngine ajudaria neste sentido - quero
dizer, disponibilizar e manter uma APO pública, tipo a de código de barras,
a de extenso, ou mesmo uma outra mais sofisticada (eu estava pensando em
fazer uma API de síntese de voz para anúncios, a sua API de extensos veio a
calhar!) - o modelo de precificação se sustentaria? Até que ponto dá para
rodar uma API dessa como sendo algo "free" (ex: até X chamadas/mês) para
pequenos desenvolvedores, e um modelo pago para chamadas excedentes?
Pensei em fazer algo que ajudasse desenvolvedores e que pudesse oferecer
cada vez mais valor agregado. A idéia é antiga, veio mesmo de exemplos como
a chart API e a API de validação de CEP (que muita gente já usa), e
incluiria diversos tipos de validação: telefones, conversão de endereços (já
falamos disso aqui na lista anteriormente), e outros do tipo. A idéia do
código de barras também é boa e poderia ser "two way" - a partir de um
código, gerar a representação de barras, e também fazer a "leitura" com base
em uma imagem.
Uma outra opção seria hospedar isso em um servidor próprio. Eu disponho hoje
de hardware e banda para fazer isso, com custo baixo (poderia até ser um
investimento meu, depende de avaliar quanto).
Eu prefiro hospedar isso como serviço, porque acho a idéia mais "intrigante"
e escalável. Isso permite que o sistema cresça gradualmente e vá oferecendo
mais valor continuamente, com novos módulos.
Se você tiver interesse na idéia me dê um retorno. Estou pensando nisso como
negócio, do ponto de vista profissional, mas não necessariamente como algo
para "fazer dinheiro fácil". Por exemplo, não vejo problema em
disponibilizar todo código em formato aberto. O que me estimula é pensar
nisso como serviço, dentro da visão de que é para este caminho que a
indústria de software pode estar se encaminhando. E tem muita coisa legal
para fazer por aqui até chegar nesse ponto.
Atenciosamente,
Carlos Ribeiro
2011/3/7 Luciano Ramalho <ram...@gmail.com>
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Carlos Ribeiro
O Luciano acabou de me contar que eu mandei pra lista inteira a mensagem
abaixo... bom, não tem segredo nenhum nela, então já que está aberta, quem
quiser dar palpite, ajudar, ou "descer a lenha", que fique a vontade!!
E para quem não se interessa pelo tema, desculpem o "offtopic", foi
totalmente acidental. Como disse para o Luciano, foi "síndrome de feriado",
com neurônios operando a meia carga :-)
Carlos Ribeiro
2011/3/7 Carlos Ribeiro <carri...@gmail.com>
Ari Caldeira
Com ideias do código do Luciano, simplifiquei um pouco um código que eu tinha
feito já há bastante tempo.
É uma classe que implementa os números por extenso, cardinais, ordinais e
cardinais com unidades de medida, inteiros e decimais, masculinos e femininos,
e números negativos.
Chamando:
python extenso.py 25.69
na linha de comando você verá os exemplos de saída:
Numeral cardinal simples: vinte e cinco
Numeral ordinal simples: vigésimo quinto
Valor monetário em R$: vinte e cinco reais e sessenta e nove centavos
Valor em quilos (masculino) e gramas (feminino, com 3 casas decimais de
precisão): vinte e cinco quilos e seiscentas e noventa gramas
Valor em toneladas (feminino) e quilos (masculino, com 3 casa decimais de
precisão): vinte e cinco toneladas e seiscentos e noventa quilos
Valor em graus Celsius e décimos (com 1 casa decimais de precisão): vinte e
cinco graus Celsius e seis décimos
Valor em pontos percentuais (somente inteiros): vinte e cinco pontos
percentuais
Valor em pontos percentuais negativos (somente inteiros): menos vinte e cinco
pontos percentuais
Valor em graus Celsius negativos: vinte e cinco graus Celsius negativos
Espero que seja útil :)
---
Aristides Caldeira
Ari Caldeira
Luciano Ramalho
Python.org.br ou em algum repositório? Fica mais "permanente" (eu vi
que vc colocou para não expirar no pastebin, mas mesmo assim...).
Uma sugestão: eu reduziria as repetições naqueles vários dicionários,
fazendo como neste exemplo:
CARDINAL_FEMININO = CARDINAL_MASCULINO.copy()
CARDINAL_FEMININO.update({
1: CARDINAL_1_FEMININO,
2: CARDINAL_2_FEMININO,
200: CARDINAL_200_FEMININO,
300: CARDINAL_300_FEMININO,
400: CARDINAL_400_FEMININO,
500: CARDINAL_500_FEMININO,
600: CARDINAL_600_FEMININO,
700: CARDINAL_700_FEMININO,
800: CARDINAL_800_FEMININO,
900: CARDINAL_900_FEMININO,
}
Ou seja, assim fica claro que CARDINAL_FEMININO é uma cópia do
CARDINAL_MASCULINO, com as diferenças explicitadas.
Valeu, Ari!
[ ]s
Luciano
2011/3/7 Ari Caldeira <a...@laumi.org>:
> Ai, cabeça...
>
> Código no pastebin:
>
> http://pastebin.com/Cypftmh7
>
> ---
> Aristides Caldeira
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Luciano Ramalho
> Legal, Ari, bem completo. Você não gostaria de colocar no wiki
> Python.org.br ou em algum repositório? Fica mais "permanente" (eu vi
> que vc colocou para não expirar no pastebin, mas mesmo assim...).
>
> Uma sugestão: eu reduziria as repetições naqueles vários dicionários,
> fazendo como neste exemplo:
>
> CARDINAL_FEMININO = CARDINAL_MASCULINO.copy()
> CARDINAL_FEMININO.update({
> 1: CARDINAL_1_FEMININO,
> 2: CARDINAL_2_FEMININO,
> 200: CARDINAL_200_FEMININO,
> 300: CARDINAL_300_FEMININO,
> 400: CARDINAL_400_FEMININO,
> 500: CARDINAL_500_FEMININO,
> 600: CARDINAL_600_FEMININO,
> 700: CARDINAL_700_FEMININO,
> 800: CARDINAL_800_FEMININO,
> 900: CARDINAL_900_FEMININO,
> }
>
> Ou seja, assim fica claro que CARDINAL_FEMININO é uma cópia do
> CARDINAL_MASCULINO, com as diferenças explicitadas.
Faltou fechar parenteses...
Junior Polegato - Linux
Olá!
Muito bom! Parabéns!
Bom, não queria ser o cara chato, mas...
1. Seria interessante trabalhar com o locale, permitindo entrar com
1.234,56. Fazendo as seguintes alterações:
Legenda: = -> mantem | - -> tira | + -> adiciona
= from decimal import Decimal as D
+
+ import locale
+ locale.setlocale(locale.LC_ALL, '')
+ separador_grupo = locale.localeconv()['mon_thousands_sep']
+ separador_decimal = locale.localeconv()['mon_decimal_point']
=
= PLURAL = 1
e
= def set_numero(self, valor):
+ valor = str(valor).replace(separador_grupo,
'').replace(separador_decimal, '.')
- if D(str(valor)) > VALOR_MAXIMO:
+ if D(valor) > VALOR_MAXIMO:
= raise OverflowError('valor maior do que o máximo
permitido: %s' % VALOR_MAXIMO)
=
- self._numero = D(str(valor))
+ self._numero = D(valor)
=
= numero = property(get_numero, set_numero)
2. Um detalhe de gênero, grama feminino é planta, grama masculino é
unidade de medida, é preciso corrigir.
3. Um mero detalhe, mas não sei se é realmente necessário devido ao
jargão popular, quilo é apenas prefixo de unidade de medida e não ela
propriamente, então o correto seria quilograma (masculino), fica a dica.
Mais uma vez, parabéns pelo trabalho e obrigado por compartilhar.
[]'s
Junior Polegato
Ari Caldeira
> Legal, Ari, bem completo. Você não gostaria de colocar no wiki
> Python.org.br ou em algum repositório? Fica mais "permanente" (eu vi
> que vc colocou para não expirar no pastebin, mas mesmo assim...).
>
> Uma sugestão: eu reduziria as repetições naqueles vários dicionários,
> fazendo como neste exemplo:
>
> CARDINAL_FEMININO = CARDINAL_MASCULINO.copy()
> CARDINAL_FEMININO.update({
> 1: CARDINAL_1_FEMININO,
> 2: CARDINAL_2_FEMININO,
> 200: CARDINAL_200_FEMININO,
> 300: CARDINAL_300_FEMININO,
> 400: CARDINAL_400_FEMININO,
> 500: CARDINAL_500_FEMININO,
> 600: CARDINAL_600_FEMININO,
> 700: CARDINAL_700_FEMININO,
> 800: CARDINAL_800_FEMININO,
> 900: CARDINAL_900_FEMININO,
> }
>
> Ou seja, assim fica claro que CARDINAL_FEMININO é uma cópia do
> CARDINAL_MASCULINO, com as diferenças explicitadas.
>
Gostei do copy, não tinha pensado nisso :)
Também eliminei o dic MILHAR_CARDINAL_COM_E, que eu usava antes para saber
quando usar "e" ou espaço em branco depois do "mil".
Como faço para colocar o código no wiki?
[ ]
---
Ari Caldeira
------------------------------------
Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
Leonardo Santagada
> 1. Seria interessante trabalhar com o locale, permitindo entrar com
> 1.234,56. Fazendo as seguintes alterações:
Pra que suportar locale se o número é em pt-br?
> 2. Um detalhe de gênero, grama feminino é planta, grama masculino é
> unidade de medida, é preciso corrigir.
> 3. Um mero detalhe, mas não sei se é realmente necessário devido ao
> jargão popular, quilo é apenas prefixo de unidade de medida e não ela
> propriamente, então o correto seria quilograma (masculino), fica a dica.
ambos eu concordo (embora não seja um especialista de pt-br).
--
Leonardo Santagada
Junior Polegato - Linux
> 2011/3/9 Junior Polegato - Linux<li...@juniorpolegato.com.br>:
>
>> 1. Seria interessante trabalhar com o locale, permitindo entrar com
>> 1.234,56. Fazendo as seguintes alterações:
>>
> Pra que suportar locale se o número é em pt-br?
>
Bom, vendo por aí tem razão, então poderia colocar uma opção a mais para
identificar se o número fornecido está em pt_BR ou en_US/C/POSIX/etc,
aí, se estiver em pt_BR, "separador_grupo" é "." e "separador_decimal" é
",", senão "," e "." respectivamente.
[]'s
Junior Polegato
Ari Caldeira
escreveu:
>
> 1. Seria interessante trabalhar com o locale, permitindo entrar com
> 1.234,56. Fazendo as seguintes alterações:
> Legenda: = -> mantem | - -> tira | + -> adiciona
>
> = from decimal import Decimal as D
> +
> + import locale
> + locale.setlocale(locale.LC_ALL, '')
> + separador_grupo = locale.localeconv()['mon_thousands_sep']
> + separador_decimal = locale.localeconv()['mon_decimal_point']
> =
> = PLURAL = 1
>
> e
>
> = def set_numero(self, valor):
> + valor = str(valor).replace(separador_grupo,
> '').replace(separador_decimal, '.')
> - if D(str(valor)) > VALOR_MAXIMO:
> + if D(valor) > VALOR_MAXIMO:
> = raise OverflowError('valor maior do que o máximo
> permitido: %s' % VALOR_MAXIMO)
> =
> - self._numero = D(str(valor))
> + self._numero = D(valor)
> =
> = numero = property(get_numero, set_numero)
>
Se eu entendi seu código direito, dessa forma eu deveria sempre informar o
número formatado no padrão do locale atual do sistema, certo?
Lembrando que o uso via linha de comando não seria o uso primário da classe,
mas sim a integração com outros sistemas, e daí, impor a necessidade de
formatar o número no locale antes de usar a classe seria estranho, não?
Porque se o locale for pt_BR, separador_grupo = '.', separador_decimal = ',',
se eu passar um float, digamos, 1.5:
valor = 1.5
str(valor) = '1.5'
str(valor).replace(separador_grupo, '').replace(separador_decimal, '.') = '15'
Não?
>
> 2. Um detalhe de gênero, grama feminino é planta, grama masculino é
> unidade de medida, é preciso corrigir.
>
Ai, se a dona Eleni, minha professora de português da 8ª série, visse isso :D
rsrsrs.
Analisando melhor, acho que não existe nenhum caso de unidade no masculino e
subunidade no feminino, desde que a relação entre elas seja decimal, em
qualquer potência. Já com relações não decimais, sim: 1,5 dias poderia ser 1
dia e 12 horas, numa relação 1 = 24, ou pés e polegadas numa relação 1 = 12 e
assim por diante.
Acrescentei uma opção para dar conta dessa relação:
class NumeroPorExtenso(object):
def __init__(self, numero=0, unidade=('real', 'reais'),
genero_unidade_masculino=True,
precisao_decimal=2, unidade_decimal=('centavo', 'centavos'),
- genero_unidade_decimal_masculino=True, mascara_negativo=('menos %s',
'menos %s')):
+ genero_unidade_decimal_masculino=True, mascara_negativo=('menos %s',
'menos %s'),
+ fator_relacao_decimal=1):
self.numero = numero
self.unidade = unidade
self.genero_unidade_masculino = genero_unidade_masculino
self.precisao_decimal = precisao_decimal
+ self.fator_relacao_decimal = fator_relacao_decimal
self.unidade_decimal = unidade_decimal
.
.
.
numero = property(get_numero, set_numero)
+
+ def get_fator_relacao_decimal(self):
+ return self._fator_relacao_decimal
+
+ def set_fator_relacao_decimal(self, valor):
+ self._fator_relacao_decimal = D(str(valor))
+
+ fator_relacao_decimal = property(get_fator_relacao_decimal,
set_fator_relacao_decimal)
+
.
.
.
- decimal = int((numero - inteiro) * (10 ** self.precisao_decimal))
+ decimal = int(((numero - inteiro) * self.fator_relacao_decimal) * (10
** self.precisao_decimal))
Essa pequena alteração permitiu adicionar aos exemplos:
e.unidade = ('dia', 'dias')
e.precisao_decimal = 1
e.unidade_decimal = ('hora', 'horas')
e.genero_unidade_decimal_masculino = False
#
# Se a relação entre a unidade e a unidade decimal não for, bem,
decimal...
# No caso, se a precisão é 1, 0,1 dias são quantas horas?
#
e.fator_relacao_decimal = D('2.4')
print('Valor em dias e horas (com 1 casa decimal de precisão):',
e.extenso_unidade)
e.unidade = ('pé', 'pés')
e.precisao_decimal = 2
e.unidade_decimal = ('polegada', 'polegadas')
#
# Se a relação entre a unidade e a unidade decimal não for, bem,
decimal...
# No caso, se a precisão é 2, 0,01 pés são quantas polegadas?
# Melhor informar em Decimal para evitar problemas de arredondamento
#
e.fator_relacao_decimal = D('0.12')
print('Valor em pés e polegadas (com 2 casas decimais de precisão):',
e.extenso_unidade)
Que geram o resultado:
python extenso.py 25.12
...
Valor em dias e horas (com 1 casa decimal de precisão): vinte e cinco dias e
duas horas
Valor em pés e polegadas (com 2 casas decimais de precisão): vinte e cinco pés
e uma polegada
...
>
> 3. Um mero detalhe, mas não sei se é realmente necessário devido ao
> jargão popular, quilo é apenas prefixo de unidade de medida e não ela
> propriamente, então o correto seria quilograma (masculino), fica a dica.
>
Sim, você tem razão, o correto seria quilograma sim. Alterei também.
Código alterado já disponível no pastebin:
[]'s
---
Ari Caldeira
José Ricardo Borba
Primeiro, parabéns ao Luciano. O código é de uma clareza ímpar.
Segundo, aos dois: não existe uma gramática OFICIAL do Brasil. Existe apenas
o dicionário oficial, editado pela Academia Brasileira de Letras, para o
qual existe uma lei. Por isso, todos os autores publicam suas obras como
(nova) "gramática oficial".
Acordo ortográfico atual (1990). Vigente a partir de 01/01/2009.
http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6583.htm
http://pt.wikipedia.org/wiki/Acordo_Ortogr%C3%A1fico_de_1990
Portanto, não se preocupem à toa. O que "soar bem" já está muito bom.
Grande abraço.
José Ricardo Borba
Porto Alegre - RS
Em 7 de março de 2011 11:25, Junior Polegato - Linux <
li...@juniorpolegato.com.br> escreveu:
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------