Função is_valid segue fluxo de None quando um valor inválido é fornecido no argumento 'type'

[lucasjl]

Descrição do problema
Em arquivos onde a função is_valid() pede o argumento type (license_plate.py, phone.py), a lógica pede por strings específicas para o argumento. Em license_plate, 'type' pode ser old_format, mercosul ou None. Em phone.py, o valor pode ser 'landline' ou 'mobile'. Há uma lógica separada para cada valor, e uma lógica para o cenário em que o argumento não é fornecido (None).

No entanto, não há tratamento explícito para quando o 'type' fornecido é inválido. Se, por exemplo, o consumidor fornece o type com erro de digitação (ex: "mercosur" em vez de "mercosul"), a função trata o caso como None, onde a função verifica os dois comportamentos (um OU outro). Se o consumidor não percebe o erro de digitação e fornece uma placa de carro no formato 'old_format', a função retornaria True, podendo gerar confusão.

Acredito que deve haver um retorno diferente para quando um type inválido é fornecido, evitando enganos.

Para Reproduzir
Passos para reproduzir o comportamento:

1. Chamar utilitário is_valid_license_plate
2. Para license_plate, chamar is_valid_license_plate('ABC1234', 'mercosu') . ABC1234 é uma placa no formato old_format, e "mercosu" é um erro de digitação para o type "mercosul".
3. Observar que a função retorna True. Isso acontece pois, quando o type não é exatamente "old_format" ou "mercosul" ele verifica ambos tipos, e retorna True se pelo menos um é válido. Com isso, o consumidor recebe True ao tentar prover o parâmetro "mercosul", visto que ABC1234 passa como um método válido de old_format.

PS: O mesmo comportamento ocorre com a função is_valid_phone, onde um type inválido faz com que a função verifique ambos types ('landline', 'mobile'), da mesma maneira que faz quando nenhum type é provido.

Comportamento esperado
A função deve retornar um valor diferente quando um type inválido é provido. Conversando com o mantenedor Nilton Pimentel (niltonpimentel02), concordamos em retornar None em um primeiro momento, mas ajustar o código posteriormente para retornar uma Exception que informe o problema com mais detalhes.

Desktop (por favor, forneça as seguintes informações):

• Sistema Operacional: macOS 15.7.1

Contexto adicional
N/A

💌 Quer contribuir, mas não se sente à vontade?

Você tem vontade de contribuir, mas não se sente à vontade em abrir issues, PRs ou fazer perguntas publicamente?

Nós sabemos como pode ser difícil dar o primeiro passo em um espaço aberto. A insegurança, o medo de errar ou até a sensação de “será que minha dúvida é boba?” podem pesar bastante. E tá tudo bem sentir isso. 💜

Queremos que você saiba que aqui ninguém precisa enfrentar esse caminho sem apoio. Se preferir um espaço mais reservado, você pode mandar um e-mail para cumbucadev@gmail.com e teremos o maior prazer em ajudar. Seja para tirar dúvidas, pedir orientação ou simplesmente ter alguém para conversar sobre como começar.

O importante é que você saiba: sua participação é muito bem-vinda, e cada contribuição, por menor que pareça, faz uma grande diferença. ✨

[lucasjl]

bora

[github-actions]

🇧🇷 Português
✅ Issue #648 atribuída a @lucasjl. Verifique o guia de contribuição para instruções sobre como submeter sua Pull Request.

🇬🇧 English
✅ Issue #648 assigned to @lucasjl. Check the contributing guide for instructions on submitting your Pull Request.

[niltonpimentel02]

@lucasjl boa tarde, tudo bem? ainda quer ficar com essa issue pra trabalhar nela?

[lucasjl]

@lucasjl boa tarde, tudo bem? ainda quer ficar com essa issue pra trabalhar nela?

@niltonpimentel02 sim! mas nas próximas semanas vai ser meio impossível pra mim. Se for ok eu entregar depois, fico com ela sim. Mas se tiver alguém precisando disso ou interessado em trabalhar nela, pode ficar a vontade pra tirar meu nome.

[niltonpimentel02]

@niltonpimentel02 sim! mas nas próximas semanas vai ser meio impossível pra mim. Se for ok eu entregar depois, fico com ela sim. Mas se tiver alguém precisando disso ou interessado em trabalhar nela, pode ficar a vontade pra tirar meu nome.

é só pra eu ter mapeado aqui se os donos das issues tem ideia de trabalhar ou não.. mas sem pressa pra finalizar essa em específico!

[franzkurt]

Na verdade acredito que usar um enum, ou mais recente StrEnum, seria uma ótima escolha na hora de passar o type, assim o método sabe que pode esperar apenas os valores presentes no enum e o usuário, aquele que chamar o método, sabe as opções que possui pra usar.

Antes

if type == "old_format":
    return _is_valid_old_format(license_plate)
if type == "mercosul":
    return _is_valid_mercosul(license_plate)

Depois

In [1]: from enum import StrEnum

In [2]: class licenceTypes(StrEnum):
   ...:     OLD_FORMAT = "old_format"
   ...:     MERCOSUL = "mercosul"

In [3]: licenceTypes.OLD_FORMAT
Out[3]: <licenceTypes.OLD_FORMAT: 'old_format'>

In [4]: licenceTypes.MERCOSUL
Out[4]: <licenceTypes.MERCOSUL: 'mercosul'>

In [5]: param_type = licenceTypes.MERCOSUL

In [6]: if param_type == licenceTypes.OLD_FORMAT:
   ...:     print('Modelo antigo')
   ...: elif param_type == licenceTypes.MERCOSUL:
   ...:     print("Formato novo")
   ...: 
Formato novo

Importante: type é uma keyword reservada e geralmente não devemos utilizar.