Você pode ler a documentação da lang e torrar um pouco a mente em cada comando, não somente ler e entender, tenta imaginar como você pode usar aquilo, não somente da forma que te foi ensinado, mas tenta responder: Posso usar assim?, e assim?, etc..

Recetemente no codewars eu me deparei com uma solução simplismente genial..

Desafio: Você recebe um inteiro positivo, e retorna 'True' ou 'False' caso seja impar ou par . A solução que a maioria iria escrever seria:

def check(value):
    return True if value%2 == 0 else 'False'

A galera mais esperta escreveu algo assim:

def check(value):
    return bool(value%2)
    
#os caras do lambda

check = lambda v: bool(v%2)

Mas teve um cara que foi simplismente genial, em termos de simplicidade e boas práticas ele não levou muito crédito, porém, em conhecer a linguagem, o cara foi fera.

def check(value):
    return[True,False][value%2] 

Eu considero isso genial, por que ele sabe que x%x vai retornar 0 ou 1, e usou isso para acessar o índice correspondente no array, ele "quebrou" a forma como eu via o operador de modulo. E me fez perceber a importância de se aprofundar em cada detalhe da lang.

Rapaz, vocês foram longe viu. Essa lang que você diz, você se refere a linguagem certo?

Opá, desculpe por demorar pra responder, por algum motivo meu app de email não está notificando ações do tabnews. E , sim, lang é uma versão curta de language/pt-br: idioma, como o texto é sobre programação ao ler lang, o leitor pode inferir que se trata de linguagem de programação.

Bom, eu faria assim:

def check(value):
    return value % 2 != 0

Pois segundo a documentação, os operadores de comparação já retornam um booleano:

Comparisons yield boolean values: True or False.

Então não há a menor necessidade de ficar fazendo malabarismos para obter os valores True e False, pois já é garantido que a comparação irá retornar sempre um deles.

Eu não achei a última solução "genial". Pra mim é só uma complicação desnecessária (pois como já disse, existem operadores que retornam os valores desejados, não precisa dar essa volta toda).

Eu vejo isso mais como uma curiosidade, uma forma diferente e inusitada, porém nada prática de usar os recursos da linguagem (e que eu jamais usaria em produção). Se o objetivo era ser mais "criativo", tudo bem, mas se a ideia era ter a solução mais simples, então eu prefiro a minha :-)

Concordo com você em tudo, porém queria explicar essa sua afirmação: ``Então não há a menor necessidade de ficar fazendo malabarismos`` . Cara, no codewars tem todo tipo de dev. grade parte deles partilham a sua linha de pensamento, por exemplo, essa solução, além de muitas outras, teve muita crítica sobre os pontos que você tocou na sua resposta, porém, tem muito dev que só quer se "divertir", parece que o lema deles é: Quanto mais exótico melhor. Alguns tentam resolver tudo em uma única linha ( São as soluções com mais críticas ) outros "10 linhas é pouco". É um lugar para todo tipo de dev, é por isso que algumas soluções tem todo esse marabalismo, já que alguns devs não querem codar o "mais óbvio". Usando um outro desafio pra defender meu ponto kkk. Desafio: Uma função que recebe uma string e retorna o inverso dela. As soluções com mais votos de boas práticas eram as que usavam métodos build-in. Mas teve uma solução que teve um pouco de crítica, por não seguir boas práticas. ```python inverse = lambda _str: _str[::-1] ``` É nessas soluções exóticas que eu aprendo como usar oque leio na documentação. Espero que esse texto te faça entender o porquê dos marabalismos. eu sei que eu deveria ter colocado algo como: "Não use esse tipo de coisa em produção". Mas como nem trabalho na área, essa informação passou despercebida.
Eu não participo do codewars, mas pelo que vc disse, parece que essa "criatividade" é incentivada, então tudo bem. Mas pra código em produção, em projetos sérios, que vai ser mantido por outras pessoas, clareza e simplicidade costumam ser características mais desejáveis do que tentar ser "esperto" ou exótico. Já essa forma de inverter string não achei ruim, [*slices* servem pra isso mesmo](https://stackoverflow.com/a/509295) (não tem nada de exótico, pelo menos pra quem conhece a sintaxe, que inclusive está bem documentada).
Infelizmente sim, quando eu termino um desafio, sempre vou procurar por soluções assim. um ponto bom é que tem muito dev bom, explicando o porquê não usar. Eu mesmo costumava usar muito o operador ternário no javaScript, mas le muito comentário sobre isso afetar muito a legibilidade do códico. É como vc disse, soluções "exóticas e espertas" não são uma boa para códico em produção. Agora ficarei mais "de olho" nessas soluções, ainda continuarei buscando-as nas soluções, pra saber oque não fazer. Obrigado por isso.