O primeiro padrão apresentado tenta simplificar a maneira como construímos e manipulamos formulários. Eles utilizam como exemplo uma view padrão encontrada na maioria dos projetos:

1
2
3
4
5
6
7
8
9

def my_view(request):
    if request.method == 'POST':
        form = MyForm(request.POST)
        if form.is_valid():
            do_something()
            return redirect('/success')
    else:
        form = MyForm()
    return render('template.html', {'form': form}, request=request)

Neste exemplo, temos dois blocos if aninhados e a variável form é instanciada em dois lugares diferentes. A maneira sugerida para simplificá-lo é a seguinte:

1
2
3
4
5
6

def my_view(request):
    form = MyForm(request.POST or None)
    if form.is_valid():
        do_something()
        return redirect('/success')
    return render('template.html', {'form': form}, request=request)

Neste caso, quando submetemos este formulário, o atributo request.POST é uma instância de django.http.QueryDict, avaliado como True. Deste modo o formulário é instanciado com os valores informados pelo usuário preenchidos podendo ser validado (bound).

Caso a requisição não seja pelo método POST, este atributo não existe. O formulário é instanciado com o parâmetro None criando um formulário vazio (unbound) que nunca será válido por não possuir dados.

Aparentemente é uma boa idéia, já que diminuímos a quantidade de linhas de código melhorando um pouco a legibilidade do código e os pontos onde podemos ter erros. Porém, esta solução não funciona em 100% dos casos.

Uma situação onde não podemos utilizar esse padrão é quando temos um formulário apenas com campos de múltipla escolha como esse:

1
2
3
4
5
6
7

CHOICES=[('beatles','John'),
         ('beatles','Paul'),
         ('beatles','George'),
         ('beatles','Ringo')]

class MyForm(forms.Form):
    my_choices = forms.ChoiceField(choices=CHOICES, required=False, widget=forms.RadioSelect())

Renderizando esse formulário temos um conjunto de radio buttons. Se não selecionarmos nenhum deles e submetermos o formulário o QueryDict de request.POST é vazio, sendo avaliado como False fazendo com que eles seja instanciado com o parâmetro None que nunca será válido por ser unbound.

A documentação do Django sobre testes é superficial, apresentando diversas ferramentas que podem ser utilizadas para escrevermos os nossos testes unitários com exemplos muito simples que ajudam pouco a saber o que, quando e como testar as partes da aplicação.

A biblioteca de manipulação de formulários é uma das mais utilizadas do framework e os formulários criados possuem com muita freqüência uma grande quantidade de regras de negócios e validações que devem ser testadas.

Como na maioria das vezes utilizamos o formulário dentro de uma view, uma abordagem comum de testes é utilizar o cliente de testes do Django e fazer requisições POST na view que o utiliza passando um dicionário com os dados de preenchimento dele.

Por exemplo, temos um formulário que recebe informações de um endereço:

1
2
3
4
5
6

# forms.py
class AddressForm(forms.Form):
    street = forms.CharField(max_length=32)
    number = forms.CharField(max_length=7)
    complement = forms.CharField(max_length=10, required=False)
    city = forms.CharField(max_length=50, required=False)

O padrão mais comum de usar esse formulário é através de uma view que recebe os dados via POST, verifica se o formulário está válido e o salva caso esteja válido ou retorna uma lista de erros no caso contrário:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# views.py
def add_address(request):
    if request.method == 'POST':
        form = AddressForm(request.POST)
        if form.is_valid():
            address = form.save()
            return HttpResponseRedirect('/success/')
    else:
        form = AddressForm()
    return render_to_response('new_address.html', {'form': form})

Podemos testar esse formulário indiretamente, fazendo requisições à view add_address passando como parâmetros POST as informações desejadas e verificando o conteúdo da resposta à requisição.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# tests.py
class AddressView(TestCase):
    def test_city_is_required(self):
        self.client.login(username=self.username, password=self.password)

invalid_data = {'street': 'Baker Street',
                        'number': '123',
                        'complement': ''})
        response = self.client.post('/add_address/', data=invalid_data)

# Verificamos se existe um formulário no nosso retorno
        self.assertTrue('form' in responsexxi.context)

form = response.context['form']

# Verificamos se no formulário retornado
        # temos o erro desejado
        self.assertEqual(form.errors['city'],
                         [u"This field is required."])

Porém neste caso não estamos testando realmente o formulário e sim sua integração junto a view. Caso o formulário seja utilizado de outra maneira (em outra view por exemplo), não temos como garantir que ele continuará funcionando corretamente.

Por exemplo, ao invés de fazer o teste acima passar modificando o formulário (colocando required=True no campo city do formulário), podemos fazer essa validação direto na view. O teste passa, mas se utilizarmos este formulário em outra view não teremos essa validação.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# views.py
def add address(request):
    if request.method == 'POST':
        form = AddressForm(request.POST)
        if not form.cleaned_data['city']:
            form.errors['city'] = ['This field is required.', ]
        else:
            if form.is_valid():
                address = form.save()
                return HttpResponseRedirect('/success/')
    else:
        form = AddressForm()
    return render_to_response('new_address.html', {'form': form})

Sim, eu sei que essa é uma maneira pouco usual de resolver este problema. O ponto que quero levantar é que dependendo do que estamos testando, o código que faz o teste passar não precisa necessariamente estar dentro da classe de formulário.

Porém, como o formulário é uma classe como qualquer outra, podemos testá-la diretamente instanciando-a, preenchendo seus campos e chamando seus métodos de validação e de armazenamento diretamente, verificando então sua saída.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# tests_forms.py
class AddressFormTestCase(TestCase):
    def test_city_is_required(self):
        invalid_form = AddressForm(data={'street': 'Baker Street',
                                         'number': '221B',
                                         'complement': ''})
        self.assertFalse(invalid_form.is_valid())
        self.assertEqual(invalid_form.errors['city'],
                         [u"This field is required."])

valid_form = AddressForm(data={'street': 'Baker Street',
                                       'number': '221B',
                                       'complement': '',
                                       'city': 'London'})
        self.assertTrue(valid_form.is_valid())

# (...) Outros testes do formulário

Fazendo este teste passar:

1
2
3
4
5
6

# forms.py
class AddressForm(forms.Form):
    street = forms.CharField(max_length=32)
    number = forms.CharField(max_length=7)
    complement = forms.CharField(max_length=10, required=False)
    city = forms.CharField(max_length=50, required=True)

Como eu estou garantindo que o comportamento do formulário está correto, quando eu for testar alguma view que o utilize, eu não preciso de muitos testes. Na view de exemplo, eu preciso fazer basicamente testes para essas condições:

• Testar a renderização do formulário vazio
• Testar a submissão de um formulário preenchido com dados válidos
• Testar a submissão de um formulário preenchido com dados inválidos

Assim consigo isolar ainda mais meus testes facilitando a reutilização de partes da minha aplicação.

Cifras de Substituição Simples

Este tipo de cifra faz o mapeamento entre uma letra do alfabeto com outra, definido por alguma regra pré-estabelecida. Este mapeamento cria um alfabeto de substituição que é utilizado tanto para encriptar quanto para desencriptar uma mensagem. Considerando as 26 letras do alfabeto, é possível gerar 26! (26 fatorial) alfabetos de substituição distintos.

Apesar do número grande de alfabetos de substituição, estas cifras são facilmente quebradas através de análise de freqüência da ocorrência de letras em um idioma. Com um conjunto suficientemente grande de mensagens cifradas podemos relacionar o percentual de ocorrência das letras-cifradas com o percentual das letras no idioma do texto-cifrado. Com isso um conjunto de combinações mais viáveis pode ser descoberto e avaliado.

Exemplos de Cifras de Substituição Simples

Uma das mais conhecidas cifras de substituição simples é a Cifra de César utilizada pelo imperador romano Julius Caesar. Nesta cifra um valor de deslocamento é definido, então cada letra do texto é substituída pela letra do alfabeto referente a esse deslocamento. Por exemplo, com um deslocamento de 3, a letra A é substituída pela letra D, B se torna E e assim sucessivamente. As letras do final do alfabeto, são substituídas pelas primeiras: X se torna A, Y se torna B e Z se torna C.

Uma variação desta cifra é a ROT13 que é uma Cifra de César com deslocamento 13. A vantagem de usar esse valor para o deslocamento é que, para encriptar e para desencriptar uma mensagem, podemos utilizar o mesmo algoritmo.

Para implementar uma cifra de substituição simples em Python podemos utilizar as seguintes funções do módulo string da biblioteca padrão: maketrans para criar uma tabela de substituição e a função translate para fazer a conversão.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Exemplo da Cifra de Cesar
import string

def encrypt(message, shift):
    original = string.ascii_uppercase
    new = original[shift:] + original[:shift]
    conversion_table = string.maketrans(original, new)
    return string.translate(message.upper(), conversion_table)

def decrypt(encrypted_message, shift):
    return encrypt(encrypted_message.upper(), -shift)

Outro exemplo de cifra de substituição é a Cifra de Vigenère - uma variação da Cifra de César, descrita pela primeira vez em 1553 no livro La cifra del Sig. Giovan Battista Bellaso. É uma cifra simples de aprender e implementar.

Para encriptar uma mensagem, escolhemos uma palavra que será utilizada como chave da encriptação. Cada letra desta palavra define um deslocamento diferente que será usado na Cifra de César.

Por exemplo, se escolhermos a palavra CRIPTO para ser a chave de nossa cifra, temos os seguintes valores de deslocamentos: 3 18 9 20 15.

Queremos encriptar a seguinte frase:

TESTANDO A CIFRA DE VIGENERE

Para cada letra desta frase, usamos a Cifra de César com os deslocamentos definidos pela palavra-chave ciclicamente:

T  E  S  T  A  N  D  O  A  C  I  F  R  A  D  E  V  I  G  E  N  E  R  E
3  18 9  20 15 3  18 9  20 15 3  18 9  20 15 3  18 9  20 15 3  18 9  20
-----------------------------------------------------------------------
V  V  A  I  T  B  F  F  I  R  B  T  T  R  L  T  O  W  I  V  V  T  K  S

A maior fraqueza desta cifra é a natureza repetitiva de sua chave. Se descobrimos corretamente o tamanho da letra, então o texto cifrado pode ser quebrado por análise de freqüência do mesmo modo que a cifra de César.

Exemplo de implementação:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import string

def caesar_encrypt(message, shift):
    original = string.ascii_uppercase
    new = original[shift:] + original[:shift]
    conversion_table = string.maketrans(original, new)
    return string.translate(message.upper(), conversion_table)

def encrypt(message, key):
    message_size = len(message)
    key_size = len(key)
    multiplier = (message_size / key_size) + (message_size % key_size)
    shift_values = [ord(letter) - 65 for letter in key * multiplier]
    return ''.join([caesar_encrypt(letter, shift_values[index]) for index, letter in enumerate(message)])

def decrypt(message, key):
    message_size = len(message)
    key_size = len(key)
    multiplier = (message_size / key_size) + (message_size % key_size)
    shift_values = [ord(letter) - 65 for letter in key * multiplier]
    return ''.join([caesar_encrypt(letter, -shift_values[index]) for index, letter in enumerate(message)])

Existem diversas opções no mercado, custando a partir de R$30 (pesquisando no MercadoLivre), mas como eu queria economizar encontrei alguns projetos de suportes feitos com canos de PVC e resolvi fazer o meu. Com menos de R$7 comprei os materiais necessários (cano e cotovelos), peguei emprestado um cortador de cano de PVC (você pode usar uma uma serrinha amarela no lugar, mas dá um pouquinho mais de trabalho para cortar) e em menos de 30 minutos meu suporte estava pronto!

Materiais Necessários

• 1 cano de PVC de 20mm
• 10 cotovelos de 90 graus

Como fazer

Corte o cano de PVC com as seguintes medidas:

• 2 partes de 29cm
• 2 partes de 25cm
• 2 partes de 10cm
• 2 partes de 5cm
• 2 partes de 2.5cm

Eu calculei essas medidas com base no meu notebook que tem 38cm x 26cm. Se seu notebook for menor (ou maior), você precisa adaptar as medidas. Também cortei ele de modo a parte mais alta do suporte ficar a cerca de 10cm de altura.

Montagem

A montagem é bem simples. Observando a imagem deve ficar fácil de entender onde cada peça se encaixa. Prenda os canos bem forte dentro dos cotovelos. Não é necessário usar cola, os canos se fixam muito bem sozinhos.

Cheguei a testar em um pedaço de cano que sobrou a pintura usando tinta spray. Funciona, mas tem que tomar cuidado de não passar tinta demais, senão forma bolhas e a tinta escorre. O melhor é passar bem rápido o spray uma vez, deixando a tinta secar e repetir esse processo até conseguir que a cor fique uniforme.

Mas no fim resolvi deixar ele na cor "natural" de cano de PVC :-) Talvez um próximo (já fizeram sugestões de como fazer ele ter ajuste de altura) eu faça ele colorido.

Como temos a liberdade de utilizar diferentes versões de frameworks e pacotes, é fundamental separá-los de alguma maneira para evitar conflitos. A melhor maneira para fazer isso em projetos Python é utilizar o virtualenv.

Como o próprio nome indica, o virtualenv cria ambientes virtuais isolados de modo que, se você instalar um pacote em um deles, ele não irá afetar nenhum outro. Basicamente ele altera o sys.path que define os caminhos onde os módulos são buscados pelo interpretador.

Para ajudar no gerenciamento desses ambientes, temos o virtualenvwrapper, um conjunto de extensões para o virtualenv que facilita a criação, utilização e exclusão de ambientes. Iremos instalar as duas ferramentas no ambiente do Webfaction.

Definindo a versão padrão do Python

Nos servidores do Webfaction, a versão padrão do Python em linha de comando é a 2.6. Para utilizar a versão 2.7 é necessário criar um alias na sua conta:

• Abra uma sessão SSH na sua conta
• Edite o arquivo $HOME/.bashrc e acrescente a seguinte linha no final do arquivo:

1

alias python=python2.7

• Recarregue o arquivo com o comando: source $HOME/.bashrc
• A partir de agora, todas as sessões SSH usarão essa versão do Python como padrão

Instalando

Instalar um pacote Python nos servidores do Webfaction é muito fácil. O módulo easy_install está instalado para todos os usuários:

1
2

easy_install-2.7 pip
pip install virtualenv virtualenvwrapper

Configurando

Para completar a instalação, edite novamente o arquivo $HOME/.bashrc e adicione as seguintes configurações:

1
2
3
4
5

# set the workonhome and virtualenvwrapper_python
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python2.7
# add the virtualenvwrapper hook
source $HOME/bin/virtualenvwrapper.sh

Pronto! Você já tem o necessário para criar ambientes virtuais na sua conta.

O ciclo do TDD é muito fácil de ser ensinado. Temos apenas um pequeno conjunto de passos:

1. Adicione um teste simples de uma pequena parte da funcionalidade que você quer desenvolver. Este teste irá falhar, pois ainda a funcionalidade não foi implementada.
2. Escrever o código mais simples possível que faça este teste passar (e não faça nenhum teste anterior falhar).
3. Refatorar o código resultante (código de produção e código de teste).
4. Reiniciar o ciclo com um novo teste.

Apesar de parecer muito simples, é necessário muito cuidado e experiência para saber quais testes escrever, o que significa escrever o código mais simples possível (simples é diferente de mal-feito) e principalmente não esquecer de fazer o passo de refatoração.

Para realmente aprender TDD é necessário muito estudo com a leitura de livros, participação em Coding Dojos e principalmente escrever o máximo de código possível. A seguir eu listo alguns livros e sites que podem ser usados como referência para quem está começando ou quer aprofundar mais o estudo desta técnica.

Livros

Test Driven Development: By Example

Autor: Kent Beck

Principal referência para quem quer começar a trabalhar com TDD. O livro é dividido em três partes. Nas duas primeiras dois projetos são desenvolvidos ilustrando várias técnicas que podem ser facilmente usadas para melhorar a qualidade do projeto do seu código. Na terceira parte, padrões de organização e definição de testes e refatoração de código utilizados nas primeiras partes do livro são compilados servindo como uma ótima referência para leitura posterior.

Growing Object-Oriented Software, Guided by Tests

Autores: Steve Freeman, Nat Pryce

Considerado o livro-texto da escola londrina de TDD (a escola clássica é descrita no livro do Kent Beck). Os autores descrevem o processo que eles utilizam, os princípios que eles se guiam e algumas ferramentas utilizadas para fazer com que os testes guiem a estrutura do código orientado a objetos, e com o uso de objetos Mock descobrir e descrever relações e interações entre esses objetos. Para saber mais sobre a diferença entre a escola Londrina e a escola Clássica de TDD, leia este artigo.

Test-Driven Development: Teste e Design no Mundo Real

Autor: Mauricio Aniche

O mercado brasileiro tem poucas opções de material técnico de qualidade em português mas a editora A Casa do Código entrou no mercado recentemente com muitos títulos interessantes, entre eles esse livro escrito por um dos profissionais que é referência em TDD no país (este foi o tema de sua tese de mestrado na USP). Ainda não li o livro, mas já participei de um Workshop com o autor e acompanho o seu blog. Conhecendo o seu trabalho, fico a vontade de indicar este livro.

Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration

Autor: Ken Pugh

Este livro apresenta as idéias de ATDD (Acceptance Test-Driven Development), que incentiva a colaboração de toda a equipe do projeto (clientes, desenvolvedores e testadores) na definição de critérios claros de aceitação dos requisitos de um sistema. Apesar de não tratar de técnicas de desenvolvimento de código, é uma abordagem eficiente de definir o que precisa ser desenvolvido facilitando a utilização do TDD melhorando significativamente a qualidade do software e a produtividade dos desenvolvedores.

Refactoring: Improving the Design of Existing Code

Autores: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert

O terceiro passo do TDD é a refatoração, porém ele é freqüentemente esquecido e negligenciado. A ênfase dos programadores fica sendo escrever testes falhando, corrigindo-os o mais rapidamente possível para continuar escrevendo novos testes. Mas a refatoração é uma parte fundamental do processo. Este livro apresenta uma discussão dos princípios de refatoração com vários exemplos de como utilizá-los.

Na Internet

Refactoring Uma referência com dezenas de exemplos de como utilizar técnicas de refatoração de código. Deve estar na lista de favoritos de qualquer desenvolvedor.

Blog do Mauricio Aniche Alguns artigos sobre TDD escritos por um dos principais pesquisadores de TDD do Brasil.

Top 100 Software Testing Blogs Uma lista com links para 100 blogs sobre teste de software.

Clean Coders Uma série de vídeos feitos por Robert Martin (mais conhecido como Uncle Bob) sobre vários assuntos fundamentais para quem quer programar melhor.

Para quem nunca participou de um Coding Dojo, segue uma explicação rápida:

Um Coding Dojo é um encontro onde um grupo de programadores se reúne para praticar suas habilidades de programação resolvendo um desafio simples, mas utilizando ao máximo boas práticas (como programação em par, e TDD).

Existem vários grupos de Dojo em várias cidades e países. Aqui em Campinas, temos uma lista de discussão onde os encontros são marcados e divulgados. Ainda não temos na cidade um calendário regular de encontros como existem em outras cidades (Rio de Janeiro por exemplo), mas existem conversas para organizar Dojos regularmente em empresas da cidade (novamente, entre na lista para saber mais).

O problema

Neste primeiro Dojo, escolhemos um problema que inicialmente parecia simples. Teríamos que implementar as regras básicas de uma partida de tênis.

A linguagem escolhida (democraticamente pelo dono do notebook) para resolver o problema foi Python. Começamos a implementar a pontuação de uma partida de tênis simples (dois jogadores). Não conseguimos terminar, pois ficamos discutindo qual a melhor maneira de indicar quando a partida estava empatada ou quando um jogador estava com vantagem e já estava na hora do almoço.

O código (parcialmente) desenvolvido pode ser visualizado aqui. Quem quiser continuar o desenvolvimento, faça um fork e depois compartilhe aqui :-)

Próximos Encontros

Como muitas pessoas se interessaram pela dinâmica do Dojo, esses encontros irão se tornar parte dos evento regulares do LHC. A princípio eu estarei organizando esses encontros.

Todo primeiro sábado do mês, das 10h às 12h teremos uma sessão de Dojo. O próximo já está agendado! Será no dia 3 de novembro. ATUALIZAÇÃO: Tendo em vista o feriado do dia 2 de novembro, este mês, excepcionalmente o Dojo será no dia 10 de novembro. Não é necessário se inscrever para participar, apenas aparecer!

Este ano, o Caipira Ágil faz parte também da grade da Semana Acadêmica de Computação, facilitando com que estudantes possam participar, aumentando o público do evento.

Programação

Dividido em quatro trilhas simultâneas, teremos:

• 4 Coding Dojos em diferentes linguagens (Scala, Java, Ruby e Lua);
• 15 Lightning Talks dos mais variados assuntos;
• 9 Workshops com profissionais que são referência nacional em desenvolvimento ágil;
• Open-Space onde oficializamos a conversa de corredos dos eventos.

Saiba mais detalhes da programação no site do evento.

E como não poderíamos deixar passar, o coffe-break do Caipira Ágil promete ser ainda melhor do que o do ano passado :-)

Um exemplo de aplicação que utiliza este formato é o Trac, ferramenta para controle de mudanças em projetos de software. Cada projeto do Trac criado possui o arquivo trac.ini contendo a maioria das configurações necessárias para o seu funcionamento. Por ser altamente customizável, é interessante ter a possibilidade de alterar esses valores de configuração de uma maneira automática.

Criando um arquivo de configuração

Em Python, em sua biblioteca padrão, existe o módulo ConfigParser (renomeado para configparser no Python 3.0) que, através da classe ConfigParser fornece um conjunto de métodos para trabalhar com arquivos desse tipo.

Criar um arquivo de configuração é simples. Precisamos de uma instância da classe ConfigParser

1
2

import ConfigParser
config = ConfigParser.ConfigParser()

Essa instância (config), ainda não possui nenhuma informação (um arquivo vazio caso seja armazenada agora), então precisamos incluir seções e opções com valores nela. Vamos incluir duas seções: section1 e section2 utilizando o método add_section:

1
2

config.add_section('section1')
config.add_section('section2')

Em cada seção adicionada, podemos definir opções com seus respectivos valores utilizando o método set. O primeiro parâmetro deste método é a seção onde o valor será incluído, o segundo parâmetro é a opção e o terceiro o valor desejado.

1
2
3
4

config.set('section1', 'opcao1', 'valor1')
config.set('section1', 'opcao2', 'valor2')
config.set('section2', 'outraopcao', 'valor')
config.set('section2', 'numerico', '123')

Após essas operações, teríamos um arquivo de configuração desta maneira:

[section1]
opcao1 = valor1
opcao2 = valor2

[section2]
outraopcao = valor
numerico = 123

Abrindo um arquivo de configuração já existente

Até agora estamos criando um novo arquivo de configuração, porém normalmente o que queremos fazer é alterar as configurações de um arquivo já existente. Se tivermos um arquivo chamado config.ini, utilizamos o método read indicando como argumento, uma lista com o nome dos arquivos que devem ser lidos (nesse caso, apenas um):

1
2
3

import ConfigParser
config = ConfigParser.ConfigParser()
config.read(['config.ini'])

Feito isso, podemos manipular essa instância de ConfigParser da mesma maneira como já fizemos anteriormente.

Lendo seções e valores

Após efetuar a leitura de um arquivo de configuração, queremos ser capazes de obter as informações armazenadas nele. Por exemplo, se eu quiser saber todas as seções existentes do arquivo config.ini que estamos utilizando como exemplo:

1
2

>>> c.sections() # Retorna uma lista com todas as seções existentes
['section1', 'section2']

Sabendo o nome da seção, podemos obter todos as suas opções e valores associados:

1
2
3

>>> # Retorna uma lista de tuplas (nome, valor) para cada opção na seção informada
... c.items('section1')
[('opcao1', 'valor1'), ('opcao2', 'valor2')]

Se quisermos o valor de uma opção específica:

1
2
3

>>> # Retorna o valor da opcao2 na section1
... c.get('section1', 'opcao2')
'valor2'

O método get sempre retorna uma string. Caso saibamos com antecedência o tipo do valor que estamos obtendo, podemos usar métodos específicos: getint, getfloat e getboolean.

1
2
3
4
5
6

>>> valor = config.get('section2', 'numerico')
>>> type(valor)
<type 'str'>
>>> valor = config.getint('section2', 'numerico')
>>> type(valor)
<type 'int'>

Editando seções e valores

Como já foi apresentado, os métodos add_section e set são utilizados para adicionar novas seções e definir suas opções e valores respectivamente.

Outros métodos úteis são o remove_section, que exclui uma seção e todas as opções associadas e o remove_option que exclui uma opção em uma determinada seção.

1
2
3
4
5
6
7

>>> # Excluindo uma seção
... config.sections()
['section1', 'section2']
>>> config.remove_section('section2')
True
>>> config.sections()
['section1']

1
2
3
4
5
6
7

>>> # Excluindo uma opção
... config.items('section2')
[('outraopcao', 'valor'), ('numerico', '123')]
>>> config.remove_option('section2', 'outraopcao')
True
>>> config.items('section2')
[('numerico', '123')]

Armazenando o arquivo

A instância de ConfigParser é uma representação de um arquivo de configuração. Depois de fazer a personalização desejada, é necessário salvá-lo no sistema de arquivos. Isso é feito utilizando o método write:

Este código abre um arquivo chamado config.ini para escrita, excluindo todo o conteúdo existente e armazena a representação do arquivo de configuração:

1
2

with open('config.ini', 'w') as cfgfile:
    config.write(cfgfile)

Exemplo

Aqui temos um exemplo de como criar através de código um arquivo de configuração de uma aplicação hipotetica, indicando dados de conexão do banco de dados e repositório: https://gist.github.com/1590437

Porém existem outras maneiras de se realizar um Coding Dojo. Um outro formato, que só consegui utilizar uma vez no open-space do Caipira Ágil, é o Kake.

Neste formato, temos sempre pelo menos duas duplas trabalhando simultaneamente no mesmo problema em linguagens diferentes, em problemas diferentes na mesma linguagem ou em problemas diferentes em linguagens diferentes. A troca das duplas ocorre como no Randori (a cada 5 a 7 minutos), onde o piloto (quem está com o teclado nas mãos) troca de computador e o co-piloto (que estava ajudando o piloto), se torna o piloto.

No dia 29/10/2011, às 10h, teremos uma sessão de Coding Dojo utilizando este formato na sede do LHC (Laboratório Hacker de Campinas). Quem puder, traga o seu notebook com algum ambiente de desenvolvimento configurado. Aqui você pode encontrar mais informações sobre o Dojo e como chegar no LHC.