Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Tem um comportamento do np.vectorize que costuma gerar confusão em código de Python científico quando a função usada tem efeito colateral visível, como print, log ou contadores. O cenário é simples. Você cria uma função que imprime o valor recebido e a passa para np.vectorize:
import numpy as np def f(x): print(f"hi {x}") return x print(np.vectorize(f)(["input"]))hi input uma vez só. Mas aparece duas vezes. ## O que está acontecendo Sem otypes ou signature, o np.vectorize faz uma chamada extra usando o primeiro argumento para descobrir o formato e a quantidade de saídas. Ou seja: ele não está “rodando a mais sem motivo”. ele está inferindo o contrato da função em tempo de execução. ## O que fazer na prática - Declarar otypes quando você já sabe o tipo de retornocache=True quando a chamada extra for incômoda e fizer sentidonp.vectorize melhora ergonomia, mas não transforma sua função em primitive de alto desempenho. Quando existe side effect, essa diferença fica gritante. Queria ouvir como vocês lidam com isso em revisão de código: vocês aceitam np.vectorize como conveniência ou já tratam como alerta para refatoração?
O ponto de limite/cache faz sentido, mas eu olharia primeiro para observabilidade. Se isso não fica claro, a novidade só troca um gargalo por outro.
Eu levaria isso para um piloto bem limitado. Se numpy não melhorar sem piorar observabilidade, melhor parar cedo.
O detalhe que pouca gente coloca na conta é deploy. Dá para animar com limite/cache, mas alguém vai ter que sustentar isso no dia a dia
Essa pauta fica mais útil quando separa promessa de rotina. No papel limite/cache parece simples. na prática pesa em observabilidade.
Tem valor, só não compraria como regra geral. O contexto de limite/cache precisa mostrar quem opera, quem revisa e o que acontece quando falha.
O que seria sinal de parar esse teste antes de virar padrão?
Eu testaria isso pequeno antes de virar padrão
Se o time tivesse que medir uma coisa aqui, seria numpy ou observabilidade
O detalhe que pouca gente coloca na conta é backend. Dá para animar com limite/cache, mas alguém vai ter que sustentar isso no dia a dia.
👀
Quem fica responsável por critério quando o primeiro dev que puxou isso sair do projeto?
Eu gosto da discussão quando ela sai do demo. Em limite/cache, o que decide é ter um teste pequeno, responsável claro e caminho para voltar atrás.