Fórum de discussão geral

Apesar de eu particularmente não ter tido dificuldades com o corretor, acho que o maior problema dele é o fato de ele correr com o Python 2.7. Ouvi o professor falando isso, e vai totalmente contra a proposta de uniformizar a utilização do programa na versão 3.x pelos alunos por uma maior compatibilidade. Por exemplo, o problema da tabulação, da falta de tab dentro do main(), discutida umas 3 vezes. O Python 3.7 aparentemente não morre tentando rodar o código sem indentação, mas o corretor, usando Python 2.x, dá erro. Contudo, acho que seus erros por enquanto estão sendo detalhes, como a existência de espaço antes dos dois pontos quando não deveria haver. No meu ver, a proposta do EP não é só fazer o programa funcionar, mas também exercitar a atenção aos detalhes e "etiqueta" da linguagem.

Boa noite, Daiane.

Quanto à sua pergunta, é importante notar que um erro no código não se trata apenas de um erro de sintaxe ou da linguagem, que possa gerar um Traceback ou algum outro tipo de aviso. Por exemplo, se você precisa fazer um programa que multiplica os números x e y, mas você digitar "x/y", não haverá nenhum tipo de aviso, pois o programa não sabe das suas intenções e não tem como saber que aquilo está incorreto. Ou seja, usar a função errada, mas escrevê-la da forma correta, não gerará Traceback Error, mas continuará sendo um erro no código.

 

Quanto aos seus apontamentos sobre o corretor:

 

1. O avaliador realmente não informa exatamente qual o erro, mas isso acontece para que o aluno busque depurar seu programa e conferir seu código para encontrar o erro, pra que possa aprender com isso, ao invés de o avaliador simplesmente lhe mostrar o erro exato. Além disso, impede que o avaliador seja utilizado para ficar corrigindo o código muitas vezes, por mais que hajam tentativas limitadas. No entanto, o avaliador dá um norte de onde está o erro, pra não deixar o aluno totalmente perdido. O seu caso é um exemplo disso. Ao dizer que "seu programa explodiu", ele mostra que o problema identificado encontra-se no loop do comando while, que por algum motivo não está se encerrando, isto é, temos um loop infinito. A partir disso o aluno pode procurar o que está causando esse loop infinito (talvez um contador que não está sendo incrementado, por exemplo.)

2. O avaliador sabe descontar notas, e também faz isso na verdade, em alguns testes aleatórios. Para os testes relativos aos exemplos, no entanto, o desconto é total. Concordo com você que colocar um espaço a mais antes dos dois pontos, por exemplo, não altera a legibilidade e o funcionamento do código, mas não é o que está sendo pedido. E é por isso que os testes referentes aos exemplos tem desconto total. Os exemplos mostram exatamente como deve ser o seu resultado, e se o programa não faz isso, então ocorre o desconto. Isso porque o aluno consegue saber exatamente o que deveria acontecer, e portanto, deve mudar seu código para que fique de acordo.

 

3. As tentativas limitadas do EP tem o objetivo de impedir que os alunos testem o programa pelo avaliador inúmeras vezes antes de enviá-lo, fazendo com que eles tenham que depurar seus programas por conta própria através do Spyder. Nessa depuração também deve entrar em conta observar se os prints estão exatamente como no enunciado, como o número de espaços e etc, e não apenas se o programa está rodando sem Traceback Errors ou coisas assim.

Dito isso, discordo no ponto em que você diz que seriam necessárias mais de 10 tentativas para corrigir os espaços. Isso porque, ao perceber o primeiro erro na falta do espaço, o aluno já deve analisar novamente todos os seus prints em busca de erros semelhantes, observando no Spyder e comparando com os exemplos, até acreditar que não há mais erros. Nisso ele gastou apenas uma tentativa. Se ao rodar o programa ele encontrar outro erro, ainda haverá 8 chances de envio para corrigi-lo.

Desta forma, o avaliador deve sim ser levado em conta, pois fornece um norte para o aluno identificar seus erros e, eventualmente, atribui a nota para os alunos. O corretor é muito válido para o aprendizado das pessoas justamente por não entregar o erro de forma exata, para que o aluno revise o programa, procure o erro e o arrume. Por mais que erros como esses de print não comprometam o código, esse é apenas um dos muitos tipos de erro que o corretor consegue detectar e informar os alunos. E esses erros geralmente tem muita relevância na verdade. O caso do loop infinito é um bom exemplo, apontar uma explosão do programa para o aluno é muito útil para que ele entenda como o while realmente funciona e o que deve ser feito para que ele se encerre da forma correta sem estourar o código.

 

Se tiver novos problemas nos próximos EPs, não deixe o avaliador de lado e não hesite em postar aqui no fórum, ou tirar suas dúvidas com os professores ou na monitoria. Boa sorte nos próximos EPs, 

 

João G.