Pense em phyton, python, Manuais, Projetos, Pesquisas de Programação em Windows

Baixe Pense em phyton, python e outras Manuais, Projetos, Pesquisas em PDF para Programação em Windows, somente na Docsity!

Prefácio

A estranha história deste livro

Em janeiro de 1999 eu me preparava para dar aula a uma turma de programação introdutória em Java. Já tinha dado esse curso três vezes e estava ficando frustrado. O índice de aprovação era muito baixo e mesmo entre os alunos aprovados, o nível geral das notas era baixo demais.

Um dos problemas que eu via eram os livros. Eram muito grandes, com detalhes desnecessários sobre o Java, e não havia orientação de alto nível sobre como programar. E todos eles sofriam do efeito alçapão: no início era fácil, os alunos iam aprendendo aos poucos, e lá pelo Capítulo 5, perdiam o chão. Era muito material novo, muito rápido, e eles acabavam engatinhando no resto do semestre.

Duas semanas antes do primeiro dia de aula, eu decidi escrever meu próprio livro. Meus objetivos eram:

que o livro fosse curto. Era melhor os alunos lerem 10 páginas que não lerem 50. abordar o vocabulário com cuidado. Tentei minimizar o jargão e definir cada termo no momento do primeiro uso. construir o aprendizado passo a passo. Para evitar alçapões, dividi os tópicos mais difíceis e em uma série de etapas menores. que o conteúdo fosse concentrado em programar mesmo, não na linguagem de programação. Selecionei um subconjunto mínimo útil do Java e omiti o resto.

Eu precisava de um título, então, por capricho, decidi chamá-lo de Pense como um cientista da computação.

A minha primeira versão era apenas um esboço, mas funcionou. Os alunos liam e entendiam o suficiente para podermos usar o tempo de aula para os tópicos difíceis, interessantes e (o mais importante) para permitir que os alunos praticassem.

Lancei o livro sob uma Licença de Documentação Livre GNU, que permite aos usuários copiar, modificar e distribuir o livro.

E o que aconteceu em seguida foi legal. Jeff Elkner, um professor de ensino médio na Virgínia adotou meu livro e o traduziu para Python. Ele me enviou uma cópia de sua tradução e tive a experiência excepcional de aprender Python lendo o meu próprio livro. Com a editora Green Tea, publiquei a primeira versão em Python em 2001.

Em 2003 comecei a trabalhar no Olin College e a ensinar Python pela primeira vez na vida. O contraste com o Java era notável. Os estudantes tinham menos dificuldades, aprendiam mais, trabalhavam em projetos mais interessantes e geralmente se divertiam muito mais.

Monoespaçado

Usada para código de programa, bem como dentro de parágrafos para referir-se a elementos do programa, como nomes de variáveis ou de funções, bancos de dados, tipos de dados, variáveis de ambiente, instruções e palavras-chave.

Monoespaçado negrito

Exibe comandos ou outros textos que devem ser digitados literalmente pelo usuário.

Monoespaçado itálico

Exibe textos que devem ser substituídos por valores fornecidos pelos usuários ou por valores determinados pelo contexto.

Uso do código dos exemplos (de acordo com a política da

O’Reilly)

Há material suplementar (exemplos de código, exercícios etc.) disponível para baixar em http://www.greenteapress.com/thinkpython2/code.

Este livro serve para ajudar você a fazer o que precisa. Em geral, se o livro oferece exemplos de código, você pode usá-los nos seus programas e documentação. Não é preciso entrar em contato conosco para pedir permissão, a menos que esteja reproduzindo uma porção significativa do código. Por exemplo, escrever um programa que use vários pedaços de código deste livro não exige permissão. Vender ou distribuir um CD-ROM de exemplos dos livros da O’Reilly exige permissão. Responder a uma pergunta citando este livro e reproduzindo exemplos de código não exige permissão. Incorporar uma quantidade significativa de exemplos de código deste livro na documentação do seu produto exige permissão.

Agradecemos, mas não exigimos, crédito. O crédito normalmente inclui o título, o autor, a editora e o ISBN. Por exemplo: “ Pense em Python , 2ª edição, por Allen B. Downey (O’Reilly). Copyright 2016 Allen Downey, 978-1-4919-3936-9.”

Se acreditar que o seu uso dos exemplos de código não se ajusta à permissão dada anteriormente, fique à vontade para entrar em contato conosco pelo email [email protected].

Como entrar em contato conosco

Envie comentários e dúvidas sobre este livro à editora, escrevendo para: [email protected].

Temos uma página web para este livro na qual incluímos erratas, exemplos e quaisquer outras informações adicionais.

Página da edição em português

http://www.novatec.com.br/catalogo/7522508-pense-em-python

Página da edição original em inglês

http://bit.ly/think-python_2E

Para obter mais informações sobre os livros da Novatec, acesse nosso site em http://www.novatec.com.br.

Agradecimentos

Muito obrigado a Jeff Elkner, que traduziu meu livro de Java para o Python, o que deu início a este projeto e me apresentou ao que acabou sendo a minha linguagem favorita.

Agradeço também a Chris Meyers, que contribuiu em várias seções do Pense como um cientista da computação.

Obrigado à Fundação do Software Livre pelo desenvolvimento da Licença de Documentação Livre GNU, que me ajudou a tornar possível a colaboração com Jeff e Chris, e ao Creative Commons pela licença que estou usando agora.

Obrigado aos editores do Lulu, que trabalharam no Pense como um cientista da computação.

Obrigado aos editores da O’Reilly Media, que trabalharam no Pense em Python.

Obrigado a todos os estudantes que trabalharam com versões anteriores deste livro e a todos os contribuidores (listados a seguir) que enviaram correções e sugestões.

Lista de contribuidores

Mais de cem leitores perspicazes e atentos enviaram sugestões e correções nos últimos anos. Suas contribuições e entusiasmo por este projeto foram inestimáveis.

Se tiver alguma sugestão ou correção, por favor, envie um email a [email protected]. Se eu fizer alguma alteração baseada no seu comentário, acrescentarei seu nome à lista de contribuidores (a menos que você peça para eu omitir a informação).

Se você incluir pelo menos uma parte da frase onde o erro aparece, é mais fácil para eu procurá-lo. Também pode ser o número da página e seção, mas aí é um pouquinho mais difícil de encontrar o erro a ser corrigido. Obrigado!

Lloyd Hugh Allen enviou uma correção da Seção 8.4. Yvon Boulianne enviou a correção de um erro semântico no Capítulo 5. Fred Bremmer enviou uma correção da Seção 2.1. Jonah Cohen escreveu os scripts em Perl para converter a fonte de LaTeX deste livro para o belo HTML. Michael Conlon enviou uma correção gramatical do Capítulo 2 e uma melhoria no estilo do Capítulo 1, além de iniciar a discussão sobre os aspectos técnicos de

Peter Winstanley nos avisou sobre um erro antigo no latim do Capítulo 3.

Chris Wrobel fez correções ao código no capítulo sobre arquivos E/S e exceções.

Moshe Zadka fez contribuições inestimáveis para este projeto. Além de escrever o primeiro rascunho do capítulo sobre Dicionários, ele forneceu orientação contínua nas primeiras etapas do livro.

Christoph Zwerschke enviou várias correções e sugestões pedagógicas, e explicou a diferença entre gleich e selbe.

James Mayer enviou-nos um monte de erros tipográficos e ortográficos, inclusive dois da lista de contribuidores.

Hayden McAfee percebeu uma inconsistência potencialmente confusa entre dois exemplos.

Angel Arnal faz parte de uma equipe internacional de tradutores que trabalhou na versão do texto para o espanhol. Ele também encontrou vários erros na versão em inglês.

Tauhidul Hoque e Lex Berezhny criaram as ilustrações do Capítulo 1 e melhoraram muitas das outras ilustrações.

O Dr. Michele Alzetta pegou um erro no Capítulo 8 e enviou alguns comentários pedagógicos interessantes e sugestões sobre Fibonacci e o jogo do Mico.

Andy Mitchell pegou um erro de ortografia no Capítulo 1 e um exemplo ruim no Capítulo 2.

Kalin Harvey sugeriu um esclarecimento no Capítulo 7 e achou alguns erros de ortografia.

Christopher P. Smith encontrou vários erros de ortografia e ajudou-nos a atualizar o livro para o Python 2.2.

David Hutchins encontrou um erro de ortografia no prefácio.

Gregor Lingl é professor de Python em uma escola de Ensino Médio em Viena, na Áustria. Ele está trabalhando em uma tradução do livro para o alemão e encontrou alguns erros feios no Capítulo 5.

Julie Peters achou um erro de ortografia no prefácio.

Florin Oprina enviou uma melhoria para o makeTime, uma correção no printTime e um belo erro de ortografia.

D. J. Webre sugeriu um esclarecimento no Capítulo 3.

Ken encontrou um punhado de erros nos Capítulos 8, 9 e 11.

Ivo Wever achou um erro de ortografia no Capítulo 5 e sugeriu um esclarecimento no Capítulo 3.

Curtis Yanko sugeriu um esclarecimento no Capítulo 2.

Ben Logan enviou vários erros de ortografia e problemas com a tradução do livro

para HTML.

Jason Armstrong percebeu que faltava uma palavra no Capítulo 2.

Louis Cordier notou um ponto no Capítulo 16 onde o código não correspondia com o texto.

Brian Caim sugeriu vários esclarecimentos nos Capítulos 2 e 3.

Rob Black entregou um monte de correções, inclusive algumas alterações para Python 2.2.

Jean-Philippe Rey, da École Centrale Paris, enviou uma série de patches, inclusive algumas atualizações do Python 2.2 e outras melhorias bem pensadas.

Jason Mader, da George Washington University, fez uma série de sugestões e correções úteis.

Jan Gundtofte-Bruun nos lembrou de que “un erro” é um erro.

Abel David e Alexis Dinno nos lembraram de que o plural de “matriz” é “matrizes”, não “matrixes”. Este erro esteve no livro por anos, mas dois leitores com as mesmas iniciais informaram a respeito dele no mesmo dia. Bizarro.

Charles Thayer nos estimulou a sumir com os pontos e vírgulas que tínhamos posto no final de algumas instruções e a otimizar nosso uso de “argumento” e “parâmetro”.

Roger Sperberg indicou uma parte distorcida de lógica no Capítulo 3.

Sam Bull indicou um parágrafo confuso no Capítulo 2.

Andrew Cheung indicou duas ocorrências de “uso antes da definição”.

C. Corey Capel notou uma palavra ausente e um erro de ortografia no Capítulo 4.

Alessandra ajudou a eliminar algumas coisas confusas do Turtle.

Wim Champagne encontrou uma confusão de palavras em um exemplo de dicionário.

Douglas Wright indicou um problema com a divisão pelo piso em arc.

Jared Spindor encontrou uma confusão no fim de uma frase.

Lin Peiheng enviou várias sugestões muito úteis.

Ray Hagtvedt enviou dois erros e um quase erro.

Torsten Hübsch indicou uma inconsistência no Swampy.

Inga Petuhhov corrigiu um exemplo no Capítulo 14.

Arne Babenhauserheide enviou várias correções úteis.

Mark E. Casida é é bom em encontrar palavras repetidas.

Scott Tyler preencheu um que faltava. E em seguida enviou um monte de correções.

Gordon Shephard enviou várias correções, todas em emails separados.

Andrew Turner notou um erro no Capítulo 8.

Wei Huang notou vários erros tipográficos.

Karen Barber achou o erro de ortografia mais antigo no livro.

Nam Nguyen encontrou um erro de ortografia e indicou que usei o Decorator, mas não mencionei o nome.

Stéphane Morin enviou várias correções e sugestões.

Paul Stoop corrigiu um erro de ortografia em uses_only.

Eric Bronner indicou uma confusão na discussão da ordem de operações.

Alexandros Gezerlis definiu um novo padrão para o número e a qualidade das sugestões que enviou. Estamos profundamente gratos!

Gray Thomas sabe diferenciar a direita da esquerda.

Giovanni Escobar Sosa enviou uma longa lista de correções e sugestões.

Alix Etienne corrigiu uma das URLs.

Kuang He encontrou um erro de ortografia.

Daniel Neilson corrigiu um erro sobre a ordem de operações.

Will McGinnis indicou que polyline foi definida de forma diferente em dois lugares.

Swarup Sahoo notou que faltava um ponto e vírgula.

Frank Hecker indicou que um exercício estava mal especificado e encontrou alguns links quebrados.

Animesh B me ajudou a esclarecer um exemplo confuso.

Martin Caspersen encontrou dois erros de arredondamento.

Gregor Ulm enviou várias correções e sugestões.

Dimitrios Tsirigkas sugeriu que eu esclarecesse um exercício.

Carlos Tafur enviou uma página de correções e sugestões.

Martin Nordsletten encontrou um bug na solução de um exercício.

Lars O.D. Christensen encontrou uma referência quebrada.

Vitor Simeone encontrou um erro de ortografia.

Sven Hoexter indicou que uma entrada de uma variável nomeada se sobrepõe a uma função integrada.

Viet Le encontrou um erro de ortografia.

Stephen Gregory indicou o problema com cmp no Python 3.

Matthew Shultz me avisou sobre um link quebrado.

Lokesh Kumar Makani me avisou sobre alguns links quebrados e algumas alterações em mensagens de erro.

Ishwar Bhat corrigiu minha declaração do último teorema de Fermat.

Brian McGhie sugeriu um esclarecimento.

Andrea Zanella traduziu o livro para o italiano e enviou uma série de correções ao longo do caminho.

Muito, muito obrigado a Melissa Lewis e Luciano Ramalho pelos comentários e sugestões excelentes na segunda edição.

Obrigado a Harry Percival do PythonAnywhere por ajudar as pessoas a começar a usar o Python em um navegador.

Xavier Van Aubel fez várias correções úteis na segunda edição.

usou, complicado ou não, é composto de instruções muito parecidas com essas. Podemos então chegar à conclusão de que programar é o processo de quebrar uma tarefa grande e complexa em subtarefas cada vez menores, até que estas sejam simples o suficiente para serem executadas por uma dessas instruções básicas.

1.2 - Execução do Python

Um dos desafios de começar a usar Python é ter que instalar no seu computador o próprio programa e outros relacionados. Se tiver familiaridade com o seu sistema operacional, e especialmente se não tiver problemas com a interface de linha de comando, você não terá dificuldade para instalar o Python. Mas para principiantes pode ser trabalhoso aprender sobre administração de sistemas e programação ao mesmo tempo.

Para evitar esse problema, recomendo que comece a executar o Python em um navegador. Depois, quando você já conhecer o Python um pouco mais, darei sugestões para instalá-lo em seu computador.

Há uma série de sites que ajudam a usar e executar o Python. Se já tem um favorito, vá em frente e use-o. Senão, recomendo o PythonAnywhere. Apresento instruções detalhadas sobre os primeiros passos no link http://tinyurl.com/thinkpython2e.

Há duas versões do Python, o Python 2 e o Python 3. Como elas são muito semelhantes, se você aprender uma versão, é fácil trocar para a outra. Como é iniciante, você encontrará poucas diferenças. Este livro foi escrito para o Python 3, mas também incluí algumas notas sobre o Python 2.

O interpretador do Python é um programa que lê e executa o código Python. Dependendo do seu ambiente, é possível iniciar o interpretador clicando em um ícone, ou digitando python em uma linha de comando. Quando ele iniciar, você deverá ver uma saída como esta:

Python 3.4.0 (default, Jun 19 2015, 14:20:21) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information.

As três primeiras linhas contêm informações sobre o interpretador e o sistema operacional em que está sendo executado, portanto podem ser diferentes para você. Mas é preciso conferir se o número da versão, que é 3.4.0 neste exemplo, começa com 3, o que indica que você está executando o Python 3. Se começar com 2, você está executando (adivinhe!) o Python 2.

A última linha é um prompt indicando que o interpretador está pronto para você digitar o código. Se digitar uma linha de código e pressionar Enter, o interpretador exibe o resultado:

1 + 1 2

Agora você está pronto para começar. Daqui em diante, vou supor que você sabe como inicializar o interpretador do Python e executar o código.

1.3 - O primeiro programa

Tradicionalmente, o primeiro programa que se escreve em uma nova linguagem chama-se “Hello, World!”, porque tudo o que faz é exibir as palavras “Hello, World!” na tela. No Python, ele se parece com isto:

print('Hello, World!')

Este é um exemplo de uma instrução print (instrução de impressão), embora na realidade ela não imprima nada em papel. Ela exibe um resultado na tela. Nesse caso, o resultado são as palavras:

Hello, World!

As aspas apenas marcam o começo e o fim do texto a ser exibido; elas não aparecem no resultado.

Os parênteses indicam que o print é uma função. Veremos funções no Capítulo 3.

No Python 2, a instrução print é ligeiramente diferente; ela não é uma função, portanto não usa parênteses.

print 'Hello, World!'

Esta distinção fará mais sentido em breve, mas isso é o suficiente para começar.

1.4 - Operadores aritméticos

Depois do “Hello, World”, o próximo passo é a aritmética. O Python tem operadores, que são símbolos especiais representando operações de computação, como adição e multiplicação.

Os operadores +, - e * executam a adição, a subtração e a multiplicação, como nos seguintes exemplos:

40 + 2 42 43 - 1 42 6 * 7 42 O operador / executa a divisão: 84 / 2

Pode ser que você fique intrigado pelo resultado ser 42.0 em vez de 42. Vou explicar isso na próxima seção.

Finalmente, o operador ** executa a exponenciação; isto é, eleva um número a uma potência:

6 ** 2 + 6 42

sequência de números inteiros separados por vírgulas. Aprenderemos mais sobre este tipo de sequência mais adiante.

1.6 - Linguagens formais e naturais

As linguagens naturais são os idiomas que as pessoas falam, como inglês, espanhol e francês. Elas não foram criadas pelas pessoas (embora as pessoas tentem impor certa ordem a elas); desenvolveram-se naturalmente.

As linguagens formais são linguagens criadas pelas pessoas para aplicações específicas. Por exemplo, a notação que os matemáticos usam é uma linguagem formal especialmente boa para denotar relações entre números e símbolos. Os químicos usam uma linguagem formal para representar a estrutura química de moléculas. E o mais importante:

As linguagens de programação são idiomas formais criados para expressar operações de computação.

As linguagens formais geralmente têm regras de sintaxe estritas que governam a estrutura de declarações. Por exemplo, na matemática a declaração 3 + 3 = 6 tem uma sintaxe correta, mas não 3 + = 3$6. Na química, H2O é uma fórmula sintaticamente correta, mas 2Zz não é.

As regras de sintaxe vêm em duas categorias relativas a símbolos e estrutura. Os símbolos são os elementos básicos da linguagem, como palavras, números e elementos químicos. Um dos problemas com 3 + = 3$6 é que o $ não é um símbolo legítimo na matemática (pelo menos até onde eu sei). De forma similar, 2Zz não é legítimo porque não há nenhum elemento com a abreviatura Zz.

O segundo tipo de regra de sintaxe refere-se ao modo no qual os símbolos são combinados. A equação 3 + = 3 não é legítima porque, embora + e = sejam símbolos legítimos, não se pode ter um na sequência do outro. De forma similar, em uma fórmula química o subscrito vem depois do nome de elemento, não antes.

Esta é um@ frase bem estruturada em portuguê$, mas com s*mbolos inválidos. Esta frase todos os símbolos válidos tem, mas estrutura válida sem.

Ao ler uma frase em português ou uma declaração em uma linguagem formal, é preciso compreender a estrutura (embora em uma linguagem natural você faça isto de forma subconsciente). Este processo é chamado de análise.

Embora as linguagens formais e naturais tenham muitas características em comum – símbolos, estrutura e sintaxe – há algumas diferenças:

ambiguidade As linguagens naturais são cheias de ambiguidade e as pessoas lidam com isso usando pistas contextuais e outras informações. As linguagens formais são criadas para ser quase ou completamente inequívocas, ou seja, qualquer afirmação tem exatamente um significado, independentemente do contexto. redundância Para compensar a ambiguidade e reduzir equívocos, as linguagens naturais usam

muita redundância. Por causa disso, muitas vezes são verborrágicas. As linguagens formais são menos redundantes e mais concisas. literalidade As linguagens naturais são cheias de expressões e metáforas. Se eu digo “Caiu a ficha”, provavelmente não há ficha nenhuma na história, nem nada que tenha caído (esta é uma expressão para dizer que alguém entendeu algo depois de certo período de confusão). As linguagens formais têm significados exatamente iguais ao que expressam.

Como todos nós crescemos falando linguagens naturais, às vezes é difícil se ajustar a linguagens formais. A diferença entre a linguagem natural e a formal é semelhante à diferença entre poesia e prosa, mas vai além:

Poesia As palavras são usadas tanto pelos sons como pelos significados, e o poema inteiro cria um efeito ou resposta emocional. A ambiguidade não é apenas comum, mas muitas vezes proposital. Prosa O significado literal das palavras é o mais importante e a estrutura contribui para este significado. A prosa é mais acessível à análise que a poesia, mas muitas vezes ainda é ambígua. Programas A significado de um programa de computador é inequívoco e literal e pode ser entendido inteiramente pela análise dos símbolos e da estrutura.

As linguagens formais são mais densas que as naturais, então exigem mais tempo para a leitura. Além disso, a estrutura é importante, então nem sempre é melhor ler de cima para baixo e da esquerda para a direita. Em vez disso, aprenda a analisar o programa primeiro, identificando os símbolos e interpretando a estrutura. E os detalhes fazem diferença. Pequenos erros em ortografia e pontuação, que podem não importar tanto nas linguagens naturais, podem fazer uma grande diferença em uma língua formal.

1.7 - Depuração

Os programadores erram. Por um capricho do destino, erros de programação são chamados de bugs (insetos) e o processo de rastreá-los chama-se depuração (debugging).

Programar, e especialmente fazer a depuração, às vezes traz emoções fortes. Se tiver dificuldade com certo bug, você pode ficar zangado, desesperado ou constrangido.

Há evidências de que as pessoas respondem naturalmente a computadores como se fossem pessoas. Quando funcionam bem, pensamos neles como parceiros da equipe, e quando são teimosos ou grosseiros, respondemos a eles do mesmo jeito que fazemos com pessoas grosseiras e teimosas (Reeves e Nass, The Media Equation: How People Treat Computers, Television, and New Media Like Real People and Places — A equação da mídia: como as pessoas tratam os computadores, a televisão e as novas mídias como se fossem pessoas e lugares reais ).

Um tipo que representa números com partes fracionárias. string Um tipo que representa sequências de caracteres. linguagem natural Qualquer linguagem que as pessoas falam e que se desenvolveu naturalmente. linguagem formal Qualquer linguagem que as pessoas criaram com objetivos específicos, como representar ideias matemáticas ou programas de computador; todas as linguagens de programação são linguagens formais. símbolo Um dos elementos básicos da estrutura sintática de um programa, análogo a uma palavra em linguagem natural. sintaxe As regras que governam a estrutura de um programa. análise Examinar um programa e sua estrutura sintática. bug Um erro em um programa. depuração O processo de encontrar e corrigir (depurar) bugs.

1.9 - Exercícios

Exercício 1.

É uma boa ideia ler este livro em frente a um computador para testar os exemplos durante a leitura.

Sempre que estiver testando um novo recurso, você deve tentar fazer erros. Por exemplo, no programa “Hello, World!”, o que acontece se omitir uma das aspas? E se omitir ambas? E se você soletrar a instrução print de forma errada?

Este tipo de experimento ajuda a lembrar o que foi lido; também ajuda quando você estiver programando, porque assim conhecerá o significado das mensagens de erro. É melhor fazer erros agora e de propósito que depois e acidentalmente.

1. Em uma instrução print, o que acontece se você omitir um dos parênteses ou ambos?
2. Se estiver tentando imprimir uma string, o que acontece se omitir uma das aspas ou ambas?
3. Você pode usar um sinal de menos para fazer um número negativo como -2. O que acontece se puser um sinal de mais antes de um número? E se escrever assim: 2++2?
4. Na notação matemática, zeros à esquerda são aceitáveis, como em 02. O que acontece se você tentar usar isso no Python?
5. O que acontece se você tiver dois valores sem nenhum operador entre eles?

Exercício 1.

Inicialize o interpretador do Python e use-o como uma calculadora.

1. Quantos segundos há em 42 minutos e 42 segundos?
2. Quantas milhas há em 10 quilômetros? Dica: uma milha equivale a 1,61 quilômetro.
3. Se você correr 10 quilômetros em 42 minutos e 42 segundos, qual é o seu passo médio (tempo por milha em minutos e segundos)? Qual é a sua velocidade média em milhas por hora?