25 janeiro 2013

Python 3?

Galera do mal! Eu venho aqui em busca de opiniões acerca deste ponto. A princípio esclarecerei meus pensamentos iniciais chegando ao que penso hoje e talvez fique mais fácil entender meus intentos. (sim eu me direciono à todos do curso BCC). Logo quando cheguei pensei que aprenderia C++, na verdade eu ansiava por isso. Não por nada fantástico, mas por simplesmente ter começado a estudar por C++. Foi quado o Python surgiu na história e não me chateei por simplesmente descobrir que as duas linguagens meio que se "entrelaçam". Assim que as aulas começaram eu já baixei a última versão do Python no momento 3.3. Com isso naturalmente fui forçado a aprender do modo que esta se comporta, mas nem por isso sem deixar de lado as outras versões da linguagem até por que 70% dos tutoriais e pdfs exemplificam normalmente pela versão 2.7.


Pelo que compreendi disso, desta situação, o fato de que é bom passar um tempo pra se utilizar outras versões até para que possíveis bugs sejam sanados. Ao que me consta isso ocorreu por volta de 2010-11 (estou certo?), a atualização. Por esse ponto vi muitos blogs se interessando em disseminar o Python 3, encarar por assim dizer agora. Até por que a linguagem não desenvolveu um modo de "recalxutar" programas antigos. Quero dizer, não tem outro método a não ser ir linha a linha corrigindo a problemática.
Pois bem... ai se encontra minha opinião. Mais cedo ou mais tarde já estaremos na versão 4.x (será?!) e bugs atuais corrigidos, mas meio que receosos ainda estaremos no 2.7 (2.x), migrando somente neste momento pra 3.x. Isso faz sentido de fato? As mudanças são poucas ao que vejo principalmente para iniciantes, mudanças mais profundas na linguagem eu mesmo não tenho como perceber já que é meu primeiro contato. Nem por isso deixo de saber os comportamentos antigos das coisas que estudo agora, até por que como falei é inevitável. 
Meu  posicionamento nesse caso é simples. Não vejo sentido em permanecermos na 2.7, por mais que encontremos nesse meio tempo incongruências no material atual que temos disponíveis. Isso serve até mesmo para o aprendizado, nos forçando a correr atrás de abarcar o novo diante de tanta informação ultrapassada. Isso não é por praticidade ou algo do tipo, muito pelo contrário. Vejo que vamos ter no futuro um trabalho duplo por menor que seja, pra nos atualizarmos. Podemos simplesmente quando em teste ou exercícios especificar que em linguagens anteriores o que funcionaria seria "assim e assado", em comentários e algo do tipo. Ou simplesmente encarando que a linguagem muda mesmo, é a vida.
O que vocês dizem?

24 janeiro 2013

Python 2.x versus 3.x

Procurando mais informações sobre o python e como uso o 3.3 acaba que mais cedo ou mais tarde me deparo com alterações implementadas nessas últimas versões. A primeira que vou explorar e trazer aqui será sobre o comando input().

Para quem já usa o python 3.3 já deve ter notado que o raw_input já era. E o motivo disso é muito simples:

Primeiro explicando o raw_input(): este como a maioria já sabe serve para receber dados e transforma tais dados em strings. Sejam números ou qualquer informação que seja. Já o input('') tem uma capacidade superior que é identificar o valor que está sendo colocado, mas também ele tem a capacidade de aceitar códigos, como o terminal. Basicamente, no python 2.7 se você usar input(''), você estará abrindo uma porta para alguém intervir no código. Isso pode ser bom em termos se necessário.



Já no Python 3.x a coisa ficou diferente, parcialmente. A princípio o raw_input() mudou para input('') somente, mas agora os parênteses são obrigatórios. Este é um raw_input inteligente, fazendo o que o raw não fazia que é identificar o tipo de entrada e portanto gerar tipos distintos ao invés de criar somente strings. Até ai tudo bem. Agora o antigo input(), que dava acesso à intervenções no código se tornou eval(). Basicamente com a mesma função, mas tecnicamente mais restrito, já que o input() já serve pra maioria das coisas com mais eficiência. No entanto descobri por meio deste eval que dá pra criar entradas múltiplas para variáveis diferentes.



O problema consiste somente no fato de que por meio do eval se pode intervir no código com códigos. Basicamente o processo de entrada eval vai tentar usar os dados, se estes significarem algo pra linguagem de modo a fazer com que este código seja usado como se já fosse uma implementação. Podendo criar quebras e travamentos.

De qualquer modo acredito ser muito simples impedir tal ocorrência por meio do .replace. Ainda não testei devidamente, mas parece ser uma saída. Logo quando testar atualizo o post.

Uma das fontes que utilizei para fazer esse post fala que não há modo seguro com eval(), o que é uma pena. Link

21 janeiro 2013

Lista 3 Q10

Este é outro exercício do qual tive certa dificuldade, mais pelo caminho que escolhi pra fazer do que pela questão em si. Uma coisa curiosa são as variáveis "unidade" e "dezena" que tive que repetir para que funcionassem nas partes necessárias do programa. Como podem ver é basicamente pra colocar números por extenso.

Lista 3 Q9

na busca de resolver umas listas pra aula de IP essa foi uma questão que quase não consigo fazer. Ela tem uma condição .replace que basicamente substitui uma coisa por outra. Procure no código que ficará fácil entender como isso é feito. O resto são condições if, elif e else. Claro que por ser iniciante está sem muito tratamento e está longe ainda de ficar estético.

...

Sem muita enrolação esse blog será um depósito do meu aprendizado em Python que estou estudando na faculdade. Aqui terá códigos e compreensões minhas e de colaboradores se aparecer.

Vou postar de tudo um pouco, falar sobre Python, C++, Java, Matemática, tecnologia móvel, Hardware... o que der na telha.