Exercícios de Python avançado com respostas

Resposta: C. Usar a base do intermediário e acrescentar engenharia: tipar, testar, medir e projetar com intenção.

O avançado reaproveita tudo do Intermediário (classes, decoradores, geradores, testes) e acrescenta a camada de engenharia: código tipado, testado, medido e bem arquitetado. Há recursos novos, mas o fio condutor é projetar com intenção, não recomeçar.

Estudar a aula: Do intermediário para o avançado: o que muda

Resposta: B. Para dar à falha um tipo próprio, que pode ser capturado com except e tratado de propósito.

Uma exceção própria dá à falha um tipo específico. Assim quem chama a função pode capturar exatamente esse erro com except SaldoInsuficienteError e reagir de forma adequada, em vez de tratar todos os erros do mesmo jeito. É a base da robustez que o módulo 12 aprofunda.

Estudar a aula: Revisão relâmpago do intermediário

Resposta: B. O Python roda mesmo assim, porque ignora os type hints em tempo de execução; quem apontaria o erro antes é o mypy.

Os type hints são documentação para o Python na hora de rodar: ele não impede tipos errados. Quem verifica os tipos sem executar, apontando a incoerência antes do bug, é o mypy. Por isso tipos e verificador andam juntos no avançado.

Estudar a aula: Seu ambiente e as ferramentas de engenharia

Resposta: C. Guarda a anotação como documentação e não impõe o tipo; a verificação fica com o mypy.

O Python registra a anotação em __annotations__ e a trata como documentação, sem impor o tipo ao rodar. Quem verifica a coerência dos tipos sem executar o código é o mypy. Por isso type hint e verificador andam juntos.

Estudar a aula: Type hints: o contrato explícito

Resposta: B. -> str | None, porque o resultado pode ser o texto encontrado ou a ausência de valor.

Como a função pode não achar nada e devolver None, o retorno é str ou None, escrito str | None (ou Optional[str]). O tipo deixa explícito o caso vazio, e o mypy passa a cobrar a checagem de None antes de usar o valor.

Estudar a aula: typing: coleções, Optional e Union

Resposta: B. Porque Any desliga a verificação de tipos naquele ponto, então o mypy para de apontar erros.

Any combina com qualquer coisa e permite qualquer operação, o que faz o mypy parar de verificar naquele ponto. Espalhado pelo código, ele anula o benefício dos tipos. Quando você quer aceitar qualquer valor mas manter a checagem, object é a escolha mais segura.

Estudar a aula: Callable, Any e apelidos de tipo

Resposta: B. Porque o Protocol verifica por comportamento: qualquer objeto com o método area serve.

O Protocol descreve o contrato por comportamento: ter o método area que devolve float. Qualquer objeto que cumpra isso satisfaz o Protocol, sem precisar herdar dele. É o duck typing, agora verificado estaticamente pelo mypy.

Estudar a aula: Generics com TypeVar e Protocol

Resposta: B. Numa biblioteca compartilhada e na lógica complexa que outras pessoas vão manter.

Os tipos rendem mais em código duradouro e compartilhado, como bibliotecas, e em lógica complexa, onde servem de documentação viva e pegam erros cedo. Em scripts descartáveis ou trechos triviais, o custo de anotar supera o benefício. A tipagem gradual permite escolher.

Estudar a aula: mypy na prática e quando tipar

Resposta: B. O __init__, o __repr__ e o __eq__, cobrindo construção, exibição e comparação.

A partir dos campos anotados, @dataclass gera o __init__ (construtor), o __repr__ (representação legível) e o __eq__ (comparação por conteúdo). Isso elimina o código repetitivo de uma classe de dados.

Estudar a aula: @dataclass: menos código, mais intenção

Resposta: B. Porque a factory cria uma lista nova para cada instância, evitando estado compartilhado.

Uma lista como default direto seria compartilhada entre todas as instâncias, um bug clássico. O default_factory recebe uma função chamada a cada objeto novo, produzindo uma lista independente por instância. Por isso o Python barra o default mutável direto e pede a factory.

Estudar a aula: field e default_factory: valores mutáveis

Resposta: B. Rodar logo após a construção para validar campos ou calcular valores derivados.

O __post_init__ é chamado automaticamente logo após o __init__ atribuir os campos. É onde você valida os valores e levanta erro se algo estiver inconsistente, garantindo que o objeto nunca nasça inválido. A imutabilidade é papel do frozen, um recurso separado.

Estudar a aula: frozen e __post_init__: imutabilidade e validação

Resposta: B. Uma namedtuple, que é imutável, leve, nomeia os campos e ainda é uma tupla.

A namedtuple é ideal para um registro pequeno e fixo: imutável, leve, acessada por nome ou posição e compatível com tuplas. Quando surge necessidade de métodos, padrões ou validação, aí a dataclass passa a valer mais a pena.

Estudar a aula: dataclass, namedtuple, dict e tupla: qual usar

Resposta: B. O Enum dá constantes nomeadas e verificáveis; um nome digitado errado gera erro na hora.

O Enum troca valores mágicos por constantes nomeadas com significado. Além da legibilidade, ele torna erros de digitação barulhentos: referenciar um membro inexistente gera erro na hora, enquanto um texto solto escrito errado passaria despercebido.

Estudar a aula: Enum: constantes nomeadas e seguras

Resposta: B. Seu resultado depende só dos argumentos e ela não causa efeitos colaterais.

Uma função pura depende apenas dos argumentos e não altera nada fora de si: mesma entrada, mesma saída, sem efeitos colaterais. Isso a torna fácil de testar, entender e reaproveitar, porque não há dependências ocultas de estado externo.

Estudar a aula: Funções puras e imutabilidade

Resposta: B. Mantém apenas os itens para os quais a função devolve verdadeiro.

filter recebe uma função de teste e um iterável, e mantém só os itens em que a função devolve verdadeiro. Quem transforma cada item é o map; quem acumula tudo num valor é o reduce, da próxima aula.

Estudar a aula: map, filter, lambda e compreensões

Resposta: B. Cria uma função nova com esses argumentos já fixados, uma versão especializada.

O partial faz aplicação parcial: fixa alguns argumentos e devolve uma função nova que só precisa dos restantes. Assim você cria versões especializadas, como quadrado a partir de uma função de potência, sem repetir a lógica.

Estudar a aula: functools: reduce e partial

Resposta: B. Porque o cache devolve o valor guardado; se o resultado depende de estado externo que muda, ele fica errado.

O cache devolve o resultado guardado para os mesmos argumentos. Se a função for impura e depender de algo externo que muda, como a hora ou um arquivo, o valor em cache ficaria desatualizado e errado. Por isso a memoização exige pureza para ser confiável.

Estudar a aula: lru_cache: memoização sem esforço

Resposta: B. Porque o groupby só agrupa itens consecutivos; sem ordenar, os iguais espalhados viram grupos separados.

O groupby junta apenas vizinhos com a mesma chave. Se os itens iguais estiverem espalhados, ele cria vários grupos separados para a mesma chave. Ordenar por essa chave antes coloca os iguais lado a lado, para que caiam num único grupo.

Estudar a aula: itertools: iteradores poderosos

Resposta: B. Para copiar os metadados (como __name__ e __doc__) da função original para o wrapper, preservando a identidade da função decorada.

Sem wraps, a função decorada assume o nome e a docstring do wrapper, perdendo a própria identidade. O functools.wraps copia __name__, __doc__ e outros metadados da função original para o wrapper, o que mantém logs, help() e ferramentas de documentação corretos.

Estudar a aula: Recap do decorador e o functools.wraps

Resposta: B. Porque @deco(arg) primeiro chama deco(arg), que precisa devolver o decorador de verdade; esse nível extra abriga a configuração.

Ao escrever @deco(arg), o Python executa deco(arg) primeiro; o retorno dessa chamada é que decora a função. Logo, deco(arg) precisa devolver um decorador. Esse nível a mais (a fábrica) recebe a configuração e devolve o decorador comum, que por sua vez devolve o wrapper.

Estudar a aula: Decorador que recebe argumentos

Resposta: B. O próprio objeto classe, que ele pode modificar e então devolver.

Um decorador de classe recebe o próprio objeto classe (não uma instância). Dentro dele você pode adicionar métodos e atributos, registrar a classe em um catálogo ou modificá-la de outras formas, e então devolve a classe, que passa a valer no lugar da original. O @dataclass é exatamente isso.

Estudar a aula: Decorar uma classe inteira

Resposta: B. f = a(b(f)), porque a aplicação vai de baixo para cima: b envolve f, e a envolve o resultado.

Decoradores empilhados se aplicam de baixo para cima. O @b, mais próximo do def, envolve f primeiro; o @a envolve o resultado. Isso equivale a f = a(b(f)). Na execução, o wrapper de a roda por fora e chama o de b, como camadas de cebola.

Estudar a aula: Empilhar decoradores e a ordem de aplicação

Resposta: B. Usar o decorador pronto functools.lru_cache, que memoiza os resultados por argumento.

A biblioteca padrão já traz o functools.lru_cache, um decorador que memoiza os retornos por argumento e descarta os menos usados quando enche. Ele exige argumentos hasháveis e uma função pura. Reinventar um cache à mão é mais trabalhoso e propenso a erros.

Estudar a aula: Casos reais: log, cronômetro, cache, validação e retry

Resposta: B. Garantir que a limpeza do recurso (como fechar um arquivo) aconteça ao sair do bloco, mesmo que uma exceção ocorra.

O with garante que o recurso seja limpo ao sair do bloco, com saída normal ou por exceção. Ele não impede erros nem acelera nada; o que faz é assegurar a limpeza sempre, transformando uma promessa frágil (fechar à mão) em uma garantia da linguagem.

Estudar a aula: Por que o with existe

Resposta: B. O valor que o método __enter__ devolve.

Ao entrar no bloco, o Python chama obj.__enter__(), e o valor retornado por esse método é atribuído à variável depois do as. Muitas vezes __enter__ devolve self (e então x é o próprio obj), mas ele pode devolver qualquer coisa, como um arquivo ou um cursor.

Estudar a aula: O protocolo __enter__ e __exit__

Resposta: B. A limpeza do recurso, equivalente ao __exit__, e deve ficar em um finally.

Na função decorada com @contextmanager, o código antes do yield é a entrada (__enter__), o valor cedido vai para o as, e o código depois do yield é a saída (__exit__). Para garantir que a limpeza rode mesmo com exceção, o yield fica em um try e a limpeza no finally.

Estudar a aula: O atalho: @contextlib.contextmanager

Resposta: B. Quando o número de recursos a gerenciar só é conhecido em tempo de execução, e todos devem ser limpos ao sair.

O ExitStack empilha uma quantidade variável de context managers, adicionados com enter_context, e garante que todos sejam limpos ao sair do bloco, na ordem inversa. É a escolha quando o número de recursos não é fixo no código. Ignorar exceções específicas é papel do suppress.

Estudar a aula: Ferramentas do contextlib: ExitStack e suppress

Resposta: B. Porque garante que o lock seja liberado mesmo se o trecho protegido lançar uma exceção, evitando que outras threads travem para sempre.

Um lock precisa ser liberado sempre. Se você liberar à mão e uma exceção pular essa linha, o lock fica fechado e todas as outras threads que o esperam travam indefinidamente. O with adquire e libera o lock automaticamente, garantindo a liberação mesmo em caso de erro. Isso é correção, não só conveniência.

Estudar a aula: Casos reais: arquivos, locks, transações e cronômetro

Resposta: B. Levantando a exceção StopIteration, que o for captura e trata como fim do laço.

Quando os valores acabam, o método __next__ levanta StopIteration. Essa exceção é um sinal combinado de fim, não um erro comum: o laço for a captura automaticamente e encerra a iteração em silêncio, sem propagar nada para o seu código.

Estudar a aula: O protocolo do iterador por dentro

Resposta: B. A dos parênteses é um gerador que produz valores sob demanda (memória quase constante); a dos colchetes constrói a lista inteira na memória.

Os parênteses criam uma generator expression, que calcula cada valor sob demanda e não guarda tudo, mantendo a memória quase constante e permitindo um único percurso. Os colchetes criam a lista completa de imediato, que ocupa memória proporcional ao tamanho, mas pode ser reutilizada.

Estudar a aula: Generator expressions e a memória

Resposta: B. Produz, um a um, todos os valores de outro_gerador, delegando a iteração a ele.

O yield from delega a produção ao gerador (ou iterável) interno: ele produz todos os valores desse objeto, um a um, como se fossem do gerador externo. Substitui o laço for x in outro: yield x e, no caso de corrotinas, também repassa valores enviados de volta.

Estudar a aula: Delegação com yield from

Resposta: B. Usar itertools.islice(gerador, 10), que consome só os 10 primeiros itens e para.

Chamar list() em um gerador infinito nunca termina, pois tenta materializar itens sem fim. O itertools.islice consome do gerador apenas a quantidade pedida, de forma preguiçosa, e para em seguida, sendo a forma segura de cortar uma sequência infinita.

Estudar a aula: Pipelines preguiçosos e geradores infinitos

Resposta: B. Retoma o gerador e envia um valor, que vira o resultado da expressão yield onde ele estava pausado.

O send retoma a execução do gerador pausado em um yield e, ao mesmo tempo, injeta um valor que se torna o resultado dessa expressão yield. É o que permite a comunicação de mão dupla, característica das corrotinas, e é a raiz conceitual do async e await modernos.

Estudar a aula: send e corrotinas: a ponte para o async

Resposta: B. Porque o GIL deixa só uma thread executar bytecode Python por vez, e cálculo puro segura a trava o tempo todo, sem revezamento.

Fatorar é uma tarefa CPU bound: as threads só calculam, nunca esperam por I/O, então nenhuma libera o GIL. Com apenas uma thread rodando bytecode por vez, elas se serializam e o ganho some. Para paralelismo real de CPU, o caminho é multiprocessing.

Estudar a aula: Concorrência, paralelismo e o GIL

Resposta: B. Porque o join logo após o start faz o programa esperar cada thread terminar antes de disparar a próxima, virando execução sequencial.

O join bloqueia até a thread acabar. Se você chama join logo depois do start, a próxima thread só começa quando a anterior termina, então nada se sobrepõe. O padrão certo é disparar todas com start e só então dar join em cada uma.

Estudar a aula: Criando threads com threading

Resposta: B. Porque a operação envolve ler, somar e gravar, e duas threads podem intercalar esses passos, perdendo incrementos.

O += não é atômico: são três passos separados. Se uma thread lê o valor, outra também lê o mesmo valor antes da primeira gravar, e ambas gravam em cima, um incremento se perde. O Lock garante que só uma thread execute esses passos por vez.

Estudar a aula: Race condition e o Lock

Resposta: B. Para avisar o consumidor de que não há mais trabalho e ele pode sair do laço e encerrar.

Um consumidor em while True fica esperando itens para sempre. O sentinela é um valor combinado que sinaliza o fim do trabalho: ao retirá-lo, o consumidor sai do laço. Com vários consumidores, coloca-se um sentinela para cada um.

Estudar a aula: Fila e o padrão produtor-consumidor

Resposta: B. ProcessPoolExecutor, porque a tarefa é CPU bound e processos rodam em paralelo real, sem o GIL travar tudo.

Cálculo pesado é CPU bound. Com threads, o GIL serializa a execução e não há ganho. O ProcessPoolExecutor usa processos separados, cada um com seu interpretador, então aproveita os vários núcleos de verdade. A interface é quase idêntica à do ThreadPoolExecutor.

Estudar a aula: ThreadPoolExecutor na prática

Resposta: B. Com threads a troca de tarefa é preemptiva (o sistema decide a qualquer hora); com async é cooperativa (só nos pontos de await).

Com threads, o sistema pode interromper e trocar a qualquer momento, o que gera race conditions e exige travas. Com async, a troca só ocorre nos pontos de await, num único thread; o modelo é cooperativo e mais previsível. Nenhum dos dois acelera cálculo puro no CPython.

Estudar a aula: O problema do I/O que espera

Resposta: B. O Python cria e devolve um objeto corrotina, sem rodar o corpo; nada é executado até você aguardar com await.

Chamar uma corrotina não executa o corpo; apenas cria um objeto corrotina. É preciso aguardá-lo com await (dentro de outra corrotina) ou entregá-lo ao asyncio.run para que o trabalho aconteça. Esquecer o await gera o aviso de coroutine never awaited.

Estudar a aula: Corrotinas: async def e await

Resposta: B. Ser a porta de entrada: iniciar o event loop, executar a corrotina principal e fechar o loop no fim.

O asyncio.run é a fronteira entre o código comum e o assíncrono: ele cria o event loop, roda a corrotina principal com todos os seus awaits e fecha o loop de forma organizada. Há um único asyncio.run no topo; lá dentro você usa await e funções como gather.

Estudar a aula: O event loop e asyncio.run

Resposta: B. Porque ele agenda as três ao mesmo tempo no event loop, e as esperas se sobrepõem em vez de somar.

O gather entrega as três corrotinas de uma vez ao event loop. Enquanto uma espera no seu asyncio.sleep, as outras também esperam nos delas, tudo sobreposto. O total vira o da mais demorada, cerca de 1 segundo, não a soma dos três.

Estudar a aula: Rodando várias tarefas com gather

Resposta: B. Porque ele bloqueia o event loop: enquanto dorme, nenhuma outra corrotina avança, e a concorrência se perde.

O event loop depende de as corrotinas cederem o controle nos pontos de await. O time.sleep é bloqueante: ele prende o único thread durante a pausa, então nenhuma outra corrotina roda. Dentro de async, use asyncio.sleep, que cede o loop enquanto espera.

Estudar a aula: Async ou threads: como escolher

Resposta: B. Permite validar o valor a cada atribuição, mantendo a sintaxe obj.atributo, sem obrigar quem usa a chamar métodos get e set.

A property intercepta leitura e escrita: o setter valida o valor a cada atribuição, protegendo as invariantes da classe. E tudo isso sem mudar a interface, quem usa continua escrevendo obj.atributo em vez de chamar getPreco e setPreco. É o encapsulamento pythônico.

Estudar a aula: property: getter, setter e validação

Resposta: B. Porque cls é a própria classe: chamar cls(...) cria a instância e faz subclasses criarem objetos delas mesmas automaticamente.

O @classmethod recebe cls, a própria classe. Ao devolver cls(...), o construtor alternativo cria uma instância da classe recebida, então uma subclasse que herda o método produz objetos dela mesma sem precisar reescrever nada. É mais organizado e reutilizável que uma função solta.

Estudar a aula: classmethod e staticmethod

Resposta: B. __repr__ é a representação técnica para desenvolvedores; __str__ é a amigável para o usuário, e print prefere __str__.

O __repr__ dá a representação técnica, sem ambiguidade, útil para quem programa e usada em console e coleções. O __str__ dá a versão amigável para o usuário, preferida pelo print. Se definir só um, defina __repr__, pois ele serve de fallback para o print.

Estudar a aula: Métodos dunder: integrando à linguagem

Resposta: B. A próxima classe na ordem de resolução de métodos (MRO), que nem sempre é o pai direto.

super() chama o próximo método na MRO, não necessariamente o pai. É isso que torna a herança cooperativa: quando cada classe chama super(), a cadeia percorre a MRO e cada classe contribui uma vez, fazendo a base comum rodar uma única vez no problema do diamante.

Estudar a aula: Herança múltipla e a ordem de resolução

Resposta: B. Economiza memória ao dispensar o dicionário interno da instância, mas impede acrescentar atributos fora da lista declarada.

Ao declarar __slots__, o Python reserva espaço fixo para os atributos e remove o __dict__ por instância, o que economiza memória de forma significativa com muitas instâncias. Em troca, você não pode criar atributos fora da lista. Vale para classes simples e numerosas com estrutura fixa.

Estudar a aula: Composição, herança e __slots__

Resposta: C. type, porque toda classe (inclusive int) é uma instância de type.

int é uma classe, e toda classe em Python é uma instância de type. Por isso type(int) devolve type. O mesmo vale para str, list e qualquer classe que você declarar com a palavra class.

Estudar a aula: Tudo é objeto: até as classes

Resposta: B. No momento em que a própria classe é criada (definida).

Uma metaclass controla a criação de classes, não de objetos. Seu __new__ e __init__ rodam quando a classe é definida. Para interceptar a criação de objetos, o método certo é o __new__ ou __init__ da própria classe, não da metaclass.

Estudar a aula: O que é uma metaclass

Resposta: B. @property é um descritor pronto: cria um objeto com __get__, __set__ e __delete__ ligados às suas funções.

property é implementada como um descritor: ao usar @property, o Python monta um objeto com __get__ (e, se você definir, __set__ e __delete__) apontando para as suas funções. Um descritor precisa de apenas um desses métodos para existir, não dos três.

Estudar a aula: Descritores: como @property funciona por dentro

Resposta: B. __getattr__ é chamado só quando o atributo não é encontrado; __getattribute__ é chamado em todo acesso.

__getattribute__ intercepta todo acesso a atributo, exista ele ou não, e por isso é perigoso e raramente sobrescrito. __getattr__ é o plano B, chamado apenas quando a busca normal falha, o que o torna ideal e seguro para proxies e valores dinâmicos.

Estudar a aula: Interceptar atributos: __getattr__ e amigos

Resposta: B. Usar __init_subclass__ na classe-base, que reage à criação de subclasses sem metaclass.

__init_subclass__ resolve o registro automático de subclasses de forma simples e legível, sem os riscos e a complexidade de uma metaclass. A metaclass fica reservada para os casos que nenhuma alternativa mais leve cobre.

Estudar a aula: __init_subclass__: o atalho para quase tudo

Resposta: B. Porque o Python usa o primeiro except que casa; a base primeiro capturaria tudo e o específico nunca rodaria.

O Python testa os except de cima para baixo e para no primeiro que casa. Se a base (mais geral) vier antes, ela captura o erro e o bloco específico nunca é alcançado. Por isso o específico vem primeiro e a base por último.

Estudar a aula: Uma hierarquia de exceções do seu domínio

Resposta: B. Levanta o novo erro preservando o original em __cause__, para o rastreamento mostrar a causa.

O raise ... from ... levanta a nova exceção e guarda a original em __cause__. O rastreamento então mostra as duas, com a frase A causa direta da exceção acima foi, contando a história completa da falha.

Estudar a aula: raise from: encadear erros sem perder a causa

Resposta: B. Porque evita checagens redundantes e a condição de corrida entre checar e agir, além de ser mais idiomático.

EAFP tenta a operação e trata a exceção, evitando duplicar a lógica de checagem e a janela de corrida em que o estado muda entre o if e o uso. É o estilo idiomático de Python, embora LBYL ainda sirva quando a falha é comum e a checagem é barata.

Estudar a aula: else, finally e o estilo EAFP

Resposta: B. logging separa níveis de severidade e destino configurável, permitindo filtrar e redirecionar sem mexer no código.

O logging tem níveis (DEBUG a CRITICAL) e destinos configuráveis por handlers e formatters. Você decide, na configuração, o que ver e para onde mandar, sem editar o código instrumentado. O print manda tudo igual para uma só saída, sem esse controle.

Estudar a aula: O módulo logging: adeus, print

Resposta: B. Porque os assert podem ser desligados (rodando com -O), então a validação sumiria em produção otimizada.

Os assert são desativados quando o Python roda no modo otimizado (-O). Se a validação de entrada dependesse deles, ela desapareceria em produção. Por isso assert serve para invariantes internas, e a validação de dados externos é feita com um if que levanta uma exceção.

Estudar a aula: Programação defensiva: validar cedo, falhar claro

Resposta: B. O nome começa com test_ e ela usa assert para verificar o resultado.

No pytest, um teste é apenas uma função cujo nome começa com test_ e que usa a instrução assert. Não há necessidade de herdar de classe nem de retornar nada: se o assert é verdadeiro, o teste passa; se é falso, falha com um relatório detalhado.

Estudar a aula: pytest: o teste que só usa assert

Resposta: B. O teardown: a limpeza executada após o teste terminar, mesmo se ele falhar.

Numa fixture com yield, o código antes do yield é o setup e o de depois é o teardown, que o pytest executa quando o teste termina, inclusive em caso de falha. É o jeito idiomático de garantir a limpeza de recursos.

Estudar a aula: Fixtures: preparar o cenário do teste

Resposta: B. Usa with pytest.raises(ValueError): e chama a função dentro do bloco.

O with pytest.raises(ValueError): afirma que o bloco levanta a exceção esperada. Se ela ocorre, o teste passa; se não, falha. O parâmetro match ainda permite conferir a mensagem, garantindo que o erro é o certo pelo motivo certo.

Estudar a aula: parametrize e testar exceções

Resposta: B. Para substituir o envio real por um dublê, evitando o efeito colateral e verificando se o código o chamou corretamente.

O mock substitui a dependência externa por um dublê controlado, evitando enviar e-mail de verdade e permitindo verificar que o seu código chamou o envio com os argumentos certos. O teste foca no seu código, não na infraestrutura de e-mail.

Estudar a aula: Mocks e monkeypatch: isolar dependências

Resposta: B. Red (teste que falha), green (código mínimo que passa) e refactor (melhorar com o teste protegendo).

O ciclo TDD é red, green, refactor: primeiro um teste que falha porque o comportamento não existe, depois o mínimo de código para ele passar, e por fim a melhoria do código com a segurança de que o teste verde avisa se algo quebrar.

Estudar a aula: Cobertura e TDD na prática

Resposta: B. Porque a intuição sobre o que é lento costuma errar, e sem medir você arrisca otimizar fora do gargalo.

A intuição humana sobre gargalos é ruim. Medir mostra onde o tempo realmente vai, evitando que você gaste esforço reescrevendo um trecho que não é o vilão. Só depois de saber onde está o gargalo faz sentido otimizar.

Estudar a aula: Medir antes de otimizar com timeit

Resposta: B. tottime é o tempo só no corpo da função; cumtime inclui também o tempo das funções que ela chama.

tottime mede o tempo gasto apenas no corpo da própria função. cumtime é cumulativo: soma o corpo da função com tudo que ela chama por dentro. Uma função que só delega trabalho tem cumtime alto e tottime baixo.

Estudar a aula: Achar o gargalo com cProfile e pstats

Resposta: B. Porque o set usa uma tabela de dispersão e vai quase direto ao valor (O(1)), enquanto a lista varre item por item (O(n)).

O set é uma tabela de dispersão: calcula onde o valor deveria estar e verifica quase direto, em tempo praticamente constante. A lista precisa varrer do início até achar, um custo que cresce com o tamanho. Por isso a busca em set é O(1) e a busca em lista é O(n).

Estudar a aula: Complexidade e a estrutura de dados certa

Resposta: B. Porque remover do início de uma lista é O(n), enquanto na deque é O(1).

Remover do início de uma lista força o Python a deslocar todos os outros itens, um custo O(n). A deque é feita para as duas pontas: adicionar e remover no início ou no fim é O(1). Para filas, essa diferença se acumula rápido.

Estudar a aula: Estruturas eficientes: deque, heapq e bisect

Resposta: B. Porque strings são imutáveis, então cada += cria uma nova string e copia todo o conteúdo anterior, virando O(n ao quadrado).

Strings são imutáveis: cada += não altera a string, ele cria uma nova copiando tudo que já existia mais o novo pedaço. Repetir isso num laço faz o custo crescer com o quadrado do tamanho. Acumular numa lista e usar str.join uma vez resolve em tempo linear.

Estudar a aula: Memoização com lru_cache e geradores para memória

Resposta: B. Módulo é um arquivo .py; pacote é uma pasta que agrupa módulos e é marcada por um __init__.py.

Um módulo é um único arquivo .py. Um pacote é uma pasta que reúne módulos relacionados e, tradicionalmente, contém um __init__.py que a marca como pacote importável. O pacote dá namespace e organização a um conjunto de módulos.

Estudar a aula: Estrutura de projeto e pacotes

Resposta: B. O import absoluto, que nomeia o caminho completo a partir da raiz do pacote.

A PEP 8 recomenda imports absolutos como padrão, porque são explícitos, fáceis de rastrear e resistem melhor à reorganização do projeto. Imports relativos com ponto são aceitáveis dentro de pacotes, mas o relativo implícito foi removido do Python moderno.

Estudar a aula: pyproject.toml e imports bem resolvidos

Resposta: B. Ele reescreve o código num estilo único e determinístico, encerrando as discussões de formatação na equipe.

O black aplica um estilo único e previsível ao código, sem opções para debater. Isso garante consistência e, principalmente, acaba com as discussões de formatação em revisão de código. Encontrar bugs, verificar tipos e rodar testes são papéis de outras ferramentas.

Estudar a aula: PEP 8 e ferramentas de estilo

Resposta: B. Uma classe deve ter apenas um motivo para mudar, concentrando uma única responsabilidade.

A responsabilidade única prega que uma classe tenha um só motivo para mudar, ou seja, uma responsabilidade bem definida. Uma classe que calcula, formata e envia mistura três assuntos e três motivos de mudança. Separar cada responsabilidade torna o código mais fácil de alterar sem quebrar o resto.

Estudar a aula: Princípios SOLID em Python

Resposta: B. Não duplicar conhecimento: cada lógica deve ter uma representação única, para que a mudança aconteça em um lugar só.

DRY significa não se repetir: cada pedaço de conhecimento ou lógica deve morar em um único lugar. Assim, uma correção é feita uma vez só, sem risco de esquecer uma cópia. Não é sobre reduzir linhas a qualquer custo, e sim sobre evitar a duplicação de conhecimento.

Estudar a aula: Padrões pythônicos e código limpo

Resposta: B. Para que cada módulo tenha um assunto claro, deixando o projeto navegável e as mudanças locais.

Dividir por responsabilidade, aplicando a responsabilidade única, faz cada módulo tratar de um assunto que cabe numa frase. Isso torna o projeto navegável e localiza as mudanças: alterar o cálculo de preço não afeta a definição dos modelos nem a infraestrutura.

Estudar a aula: Visão do projeto e arquitetura

Resposta: B. Para rodar validações ou ajustes logo após a dataclass montar o objeto, garantindo que ele seja válido.

O __post_init__ é chamado automaticamente após a dataclass criar o objeto com os campos. É o lugar certo para validar as regras do domínio, como nome não vazio e preço não negativo, levantando erro na criação. Assim, se o objeto existe, ele é válido.

Estudar a aula: Dataclasses tipadas e Enum do domínio

Resposta: B. O código de saída, executado quando o bloco with termina, mesmo se houver erro (por estar no finally).

No context manager feito com contextmanager, o código antes do yield roda na entrada do with e o código depois do yield roda na saída. Colocando-o num finally, ele executa mesmo se ocorrer um erro dentro do bloco, garantindo a limpeza ou, aqui, a medição do tempo.

Estudar a aula: Decoradores próprios e context manager

Resposta: B. Permite capturar um erro específico ou, com a base, qualquer erro da biblioteca de uma vez.

Com uma exceção base da qual todas herdam, quem usa a biblioteca pode capturar um erro exato, como PrecoInvalidoError, para tratar aquele caso, ou capturar a base CatalogoError para pegar qualquer falha da biblioteca de uma vez. A hierarquia dá essa flexibilidade de granularidade.

Estudar a aula: Exceções próprias e logging

Resposta: B. Porque provar que o código falha do jeito certo, com a exceção esperada, é parte da garantia e trava regressões.

Testar os casos de erro com pytest.raises prova que a biblioteca falha de forma previsível, levantando a exceção certa diante de entradas inválidas. Isso documenta o comportamento e impede que uma mudança futura quebre essa garantia sem ninguém perceber. Acertos e erros, os dois importam.

Estudar a aula: Testes com pytest, empacotamento e encerramento