22 de abril de 2010

La avanzada brasileña sobre empresas argentinas no se detiene, El Clarín


El mayor banco de Brasil compra el Patagonia por US$ 480 millones

Ya prevén lanzar una oferta por el 100%. La ANSeS tiene casi 15% de la institución local.




La avanzada brasileña sobre empresas argentinas no se detiene. El Banco Do Brasil, el grupo financiero más grande de América Latina, anunció ayer que tomará el control del Patagonia, con la compra de 51% del paquete accionario de la firma local por un monto que orilla los 480 millones de dólares. [Leia a íntegra]

12 de abril de 2010

Google Python Style Guide

Rodando por aí descobri que tem um google-styleguide, e que ao lado de C++ e Objective C, há o Google Python Style Guide.

De maneira geral esse guia recomenda o que já é recomendado em Python com alguns acréscimos com os quais concordo plenamente, incluindo a convenção sobre nomes:


Naming


module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_VAR_NAME, instance_var_name, function_parameter_name, local_var_name.
link
Names to Avoid
  • single character names except for counters or iterators
  • dashes (-) in any package/module name
  • __double_leading_and_trailing_underscore__ names (reserved by Python)

Naming Convention
  • "Internal" means internal to a module or protected or private within a class.
  • Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling).
  • Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module.
  • Use CapWords for class names, but lower_with_under.py for module names. Although there are many existing modules named CapWords.py, this is now discouraged because it's confusing when the module happens to be named after a class. ("wait -- did I writeimport StringIO or from StringIO import StringIO?")
***

A PEP 8, guia de estilo Python, desencoraja o uso de sublinhados em nomes de módulos, mas contrariando a PEP eu vinha usando "modulo_nome" mesmo assim, e agora vejo que não estou só.

Entretanto, não uso variáveis privadas (que iniciam com duplo sublinhado), somente internas (que começam por um único sublinhado), nunca vi necessidade de variáveis privadas em Python, mas acho que dependendo do grau de polimorfismo ou mágica talvez seja necessário usá-las.

7 de abril de 2010

Linux É "Linux"!

Há muita confusão desnecessária com o nome Linux. Criou-se uma pseudo-correção descabeçada que fez surgirem os tais: "Unix-like", "sistemas Unix", "Compatível com Unix", "Unix-family", "Posix" e "GNU/Linux".

Vamos desatar esses nós.

UNIX Bla-Bla-Bla
-----------------------
Linux foi desenvolvido baseado em Unix (pelo Minix) e com intuito de ser compatível com ele, o que não significará que ele é subproduto do Unix.

Você por acaso já ouviu alguém falar "QDOS-like" em vez de Windows, ou "Unix-like" em vez "Mac OS"?

Pois então, também não faz sentido chamar o filho do mesmo nome do pai. O Filho já cresceu, se tornou maior que o pai, de modo que a família a qual pertence Linux não é o mesmo que o nome próprio "Linux" -- o qual justamente o distingue dos demais sistemas derivados do Unix.

Esse uso só seria aceitável em casos bem restritos de aplicativos desenvolvidos para toda a família Unix, e mesmo assim seria melhor designar primeiro o sistema mais conhecido: "Desenvolvido para Linux (ou Unix-like)" ou ainda "Linux-like".

POSIX
---------
Esse aqui é ainda escabroso. Em Python se você invocar "os.name" em cima de Linux ele vai retornar "posix", mas POSIX é o nome de um conjunto de normas de interface destinada à família Unix, e jamais sinônimo de Linux, ou pior, o "nome" do sistema operacional.

GNU/LINUX
-------------------
Quem inventou esse nome foi Stallman na tentativa de se creditar ao projeto GNU o desenvolvimento de grande parte dos aplicativos de gerenciamento que rodam em cima do kernel (núcleo) de Linux.

Bem, esse nome é até aceitável. Ele envolve uma discussão abstrata e pouca precisa sobre terminologias.

Estamos certos de que o projeto GNU é importante, mas nos parece que ao criar mais um nome confuso para Linux acaba-se por atrapalhar a própria propagação dos aplicativos GNU, vez que atrapalham o fomento à adoção de Linux.