O MAIOR PROBLEMA DO PYTHON FINALMENTE RESOLVIDO

[@jeffborges101]

Muito bom o vídeo. Muito obrigado. Gostei do conteúdo e do formato com o código ao seu lado. Parabéns meu jovem. Já me inscrevi em seu canal

[@natan8381]

lembro de alguns anos atrás ver vídeos seus (não achei eles =/) onde você resolvia issues do Dynaconf. Acho um conteúdo muito interessante para poder ver como é o processo de manutenção em projeto relativamente grande. Adoraria ver mais

[@fragmendan]

Muito interessante. Eu como iniciante, sempre fico confuso e tentando o melhor caminho para iniciar um projeto e gerenciar.

[@RodrigoPinheiroMatias]

eu queria ficar feliz também, mas logo surge um outro gerenciador de projeto, acho que isto é um ponto muito ruim para o python várias pessoas atirando em direções diferentes, no final a culpa disto tudo é do EGO.

[@Garbinable]

@@fragmendan agora tu sabe que não tinha jeito melhor. Era o que tinha na cabeça da galera hahhaha. É.bom ter uma referência

[@geunb]

Coitados dos iniciantes na tua mão😂

[@enrichthesoil]

vc come iniciante?

Confesso que, pelo título, achei que o assunto seria GIL. hahahaha Eu tenho usado o UV no dia a dia, mas estava usando como substituto do pip-tools, não sabia que fazia tanta coisa. Excelente vídeo Bruno, valeu!

[@rochacbruno]

Confesso que o titulo foi proposital :) mas não é bait, eu realmente acho que a gestão de projeto é mais importante que GIL, além disso GIl está sendo bem resolvido no 3.13

[@xshiftyeuw]

Eu tava vindo aqui falar que oque eu mais odeio em Python e o GIL hahaha

[@gabrielangelo4380]

Eu tbm kkkk

[@138wilsonf]

Achei top essa ferramenta. Obrigado por compartilhar!

[@spedison]

Dependências e problemas de gestão de projetos é uma questão discutida e em algum grau dado alguma solução em qualquer linguagem. A questão é o tamanho do projeto e as relações de dependências com outros projetos. O Java é ótimo para gerir dependências. Em projetos isolados (mesmo que grandes) é excelente !! No entato, quando vc começa cruzar isso com servidores de aplicação e bibliotecas "feitas em casa"... Aí a coisa realmente complica. Eu defendo muito a implementação do tipo *NIX que eh ter projetos menores, que tenha um minino de implementações bem feitas, para facilitar integração com outros sistemas em qualquer linguagem. Essa ferramenta (UV) vou colocar na minha caixa de ferramentas para usar. Achei muito interessante. Muito Obrigado pelo vídeo e parabéns pelo trabalho.

[@mcscunha]

Bruno, como sempre EXCELENTE conteudo e MUITO didatico. Parabens.

[@gustavosiqueira1246]

Muito bom! Quem tá acostumado em projetos em typescript/javascript, react, next e afins vai se sentir familiarizado... Quem usa o bun (ou yarn) e viu o uv add [ . . . ], com certeza lembrou do bun add [ . . . ] yarn add [ . . . ] ou o próprio npm i [ . . .] Ou mudar de versão usando o nvm use node [versão] (ou algo assim, não lembro agora... hehehehehe) Essas ferramentas são extremamente úteis na hora de desenvolver. Outras linguagens tbm tem as suas, como ele mesmo falou do Rust com o cargo. Então que bom que o Python agora pode contar com algo assim tbm. Uma dica pra quem usa o Windows, eh que o UV está disponível via scoop... Dá um scoop install uv e seja feliz! Mas pode baixar via winget tbm se preferir, conforme a doc lá fala. Muito bom o vídeo, cara. Bem didático. Excelente dica! Ganhou um inscrito! 😄👍

[@marcosoliveira8731]

Boa. Muito legais seus vídeos cara!

[@ceb10n]

Muito bom Bruno! 👏🏻👏🏻

[@garcialn]

Ótimo vídeo... Seguia usando só o ruff como formater, não fazia idea dos últimos desenvolvimentos (nem do uv nem do lsp)... Fiquei curioso pra usar e queria passar de poetry pra uv, mas pelo que vi, fazer essa transição parece um processo bem manual... Espero que consigam achar melhores maneiras pra fazer transições e tornar mais flexível pra quem quer migrar...

[@ricardobrito3946]

Bruno, como sempre EXCELENTE conteúdo e MUITO didático. Realmente ótimo. E como você abriu o espaço para perguntas, lá vai a minha.. O `uv` também incorpora um gerenciador de versão padrão "Versionamento Semantico", equivalente ao bumpversion ou aos poetry version?

[@codeshowbr]

Isso aí é geralmente parte do build system, se usar setuptools pode colocar o setuptools scm, se usar o hatchling (default do uv) também tem essa feature.

[@ruansantiago3531]

Quem sofre com resolver dependência no python, não queira chegar perto de Java.

[@FodaseGoogreorio-h7v]

You didn't have stop soo low Have npm resolve dependences and than change to JS I guess that I don't thogh Now you're just a languagem that I use to know

[@isaiasprestes]

Podo dia um inferno com MAVEN :D

[@etni_dev]

Muito bom, tava faltando isso mesmo em python

[@giovanifreitasdev]

Sensacional!

[@samuelpessoa9171]

eu que pensei que só existia o pip para gerencia de pacotes no pythom agora só usar UV coisa boa obrigado por essa perola

[@newtim]

Muito bom!!! =)

[@victorbarradas6205]

gostei muito dessa solução, mas qual seria o diferencial dessa ferramenta, ao poetry? vejo o mesmo potencial, e já esta estabilizada no mercado

[@rochacbruno]

Além de ser mais rápido que o Poetry, tem suporte a mais features, é mais padronizado, se integra com o pip clássico, tem suporte a worspaces,

[@victorbarradas6205]

@@rochacbruno gostei, vou dar uma chance!

[@ricardobrito3946]

Eu uso o poetry a 4 anos. Em meus projetos multiplataforma, em ambiente linux-like, são perfeitos. Entretanto para ambiente windows; uma verdadeira tristeza. Principalmente para os casos em que o projeto deverá funcionar com mais de uma vesão de Python. e compartilho do mesmo receio que voce! 😉

[@Rildlanster]

Infelizmente nesse ramo toda suposta boa ideia precisa passar pelo teste do tempo. Veremos.

[@JCCyC]

O lance do Inline script metadata: fica ainda melhor se antes dos metadados você colocar isto aqui como primeira linha do script: #!/usr/bin/env -S uv run -q Aí você pode dar direito de execução no script e rodar ele direto.

[@afherculano]

Apenas uma opinião: Acho a linguagem Python fantástica, muito intuitiva e fácil de aprender, até o momento em que você vai fazer o primeiro projeto e se depara com todos esses problemas citados no vídeo. aí você se desestimula e desiste. Começam a surgir diversas coisas que não tem a ver com a linguagem em si. Muito bom o vídeo, se realmente solucionar esses problemas é muito bom. Quando vai lançar um curso usando o uv?

[@SergioCasasTerapias]

Muito bom o video. Bruno o som ficou bem baixo, não sei se o mic está muito longe ou embutido na câmera.

[@codeshowbr]

Meu filho está de férias, ele faz muito barulho, gravo no laptop portanto não tem chance de usar filtros, dai eu diminui o ganho para não pegar a barulheira, tentei adicionar ganho na edição mas ficou ruim...

[@SergioCasasTerapias]

@@codeshowbr é ai fica complicado rsrs, sem problema, ainda da para pegar o conteudo q é o importante.

[@littleghoost]

Sentindo falta de mais vídeos seu de Rust.

[@henriquedeandrade717]

Eu não sei se é uma boa ideia a médio prazo concentrar tanto poder e funcionalidade na mão de uma única empresa. Eu acho legal essa ferramentas novas, mas fico com um pé atrás.

[@rochacbruno]

O projeto é aberto, a qualquer momento pode rolar um fork se acontecer o que aconteceu com TErraform e REdis

[@LucasAlfare]

Se já existisse desde o começo ninguém nem ia notar; vê o Cargo por exemplo, tá lá, todo mundo usa e pronto

[@RodrigoPinheiroMatias]

fica tranquilo, irá aparece outra ferramente em pelo meno 1 ano, isto sim enfraquece o python

[@rochacbruno]

@@RodrigoPinheiroMatias Se os mesmos padrões definidos nas PEPs forem mantidos eu não vejo problemas em mudar de ferramentas

[@FodaseGoogreorio-h7v]

É código livre, a gente faz fork 🤗

[@marcelohfonseca]

Estava usando poetry, e me incomodava com algumas coisas. Sensacional o uv, vou testar.

[@FAELP22]

Tudo que vc falou é verdade, mesmo assim para criar imagens Docker com Python é outro B.O grande, sem falar da complexidade de tantas dependências e configurações que é necessário fazer e dependendo do projeto isso fica pior, isso tudo resulta em builds muito complexos e inflados que gera imagens absurdamente grandes, eu troquei o Python pelo Go em 2018 e justamente por essa bagunça, no Go tudo isso é mais simples. Outro dia pegue um projeto que tinha aproximadamente 2.6 GB o tamanho da imagem Docker e mesmo fazendo multi-stage build ainda ficou enorme, troquei por Go e pasme a imagens ficou com menos de 200MB uma redução de mais ou menos uns 2000%. Transformaram o Python em um híbrido filho de NodeJS + Java ficou muito ruim de gerenciar projetos Python hoje em dia.

[@RodrigoPinheiroMatias]

cara um exemplo bem absurdo, mas em geral as imagens de projeto python ficam maior que imagens de projetos compilados para código de máquina, de toda forma existe algo muito errado neste projeto de 2,6G que pelo que parece vc reescreveu em pouco tempo em Go

[@FAELP22]

@@RodrigoPinheiroMatias Sim essa a imagem que eu estava no projeto que peguei era absurda mesmo, e era uma do AZ Cli da Azure, eu precisava fazer com que um estagio do CI/CD fizesse a conexão com a nuvem da Azure para pegar os certificados e credencias de acesso do cluster AKS, dai fiz uma versão mais enxuta com somente o necessário para isso... Assim, isso não é culpa do Python, mas quando vc pega projetos mais grandes quando vai ver o negocio fica enorme de tantas dependências e isso não é exclusivamente deste projeto que trabalhei. Por isso que falei que o Python hoje em dia está muito absurdo de complexo na parte de dependências acho até que tá pau a pau com node_modules. A minha primeira linguagem de programação foi o Python lá em 2013, e eu ainda uso, mas se eu puder escolhe vou dar preferencias para Go pois tenho bem menos trabalho na hora da entrega e do Build. O Python tem aquele jargão de "ele vem com as baterias inclusas" eu costumo dizer que GO n tem baterias ele vem com um reator nuclear. 😉

[@heraldo623]

NodeJS é muito pior kkkk já tentou resolver conflitos num projeto com 20+ dependências? Kkk

[@alisonalmeida8499]

Que python vcs tão usando? As minhas imagens não passam de 500Mb.

[@glauciofonseca26]

Eu acho o uv muito top. Tenho usado direto.

[@hexomega9445]

+1 que achou que era um vídeo sobre o GIL! 🤣 . Mas sinceramente, gostei de saber disso... vou testar! Ótimo vídeo!

[@JoaoCarlos-df1zw]

Como é sua opinião sobre ela ser escrita em rust?? Eu acho que é um grande diferencial, e deve atrair bastante fans de rust, mas não imagino trazer tanta melhoria em performance, que eu acho ser o motivo para usar ele. Pode melhorar o startup time do app, quem o npm por exemplo é horroroso, mas não sei se nos de python é assim também. Eu acho que gerenciado de pacote é mais uma questão de usar bons algoritmos, do que ter o código mais otimizado e mais rápido

[@codeshowbr]

Rust tem boa gestão de memória e de concorrência portanto isso impacta sim na performance do algoritmo

[@1cadumagalhaes938]

Bruno, migrei alguns projetos pro uv, mas tive um pouco de dificuldade com a utilização desses projetos com pacotes. Com poetry eu estava acessando os pacotes diretamente pelo repo do git, sem fazer build ou release. Simplesmente trocar pelo uv não deu certo, acabei mantendo os dois

[@matheusnovoa5766]

Ja tem pra windows??

[@codeshowbr]

tem sim, de acordo com as docs funciona em Mac, windows e Linux

[@paulo.galvao]

Achei engraçado alguém do Ruim perguntar se tem a sua plataforma

[@gustavosiqueira1246]

Tem sim! Se tu usa o scoop: scoop install uv Se tu usa o winget: winget install --id=astral-sh.uv -e

[@antoniofernandodiasjunior8896]

Bruno, vc ainda mantém a dynaconf?

[@codeshowbr]

sim! atualmente trabalhando no type system para a versão 4.0

[@igorcruz9764]

@@codeshowbr Adorei o Dynaconf. Queria muito ter experiência para contribuir com o projeto. Parabéns!

[@andremacola_]

Finalmente vai ser mais prático desenvolver no python. Até no Node era melhor. Alguns micro serviços eu fazia em Node só por preguiça desse setup inicial com Python.

[@PyWPS]

Bruno, bons olh's o vejam Obrigad' per tares de volta.

[@sazibas]

Dê a ordem, camarada

[@tiolv1174]

Gostaria de ver um projeto utilizando workspace

[@eniebercunha]

vou precisar ver por outro local, tenho problema de audição e o audio ficou muito baixo, mesmo o volume no maximo ainda esta baixo

[@eniebercunha]

Muito bom esse video...

[@eniebercunha]

detalhe engraçado, vendo o video pelo celular também no firefox o audio é bem mais alto, fiquei na duvida se era por conta de alguma puculiariedade da renderização de video no celular ou se de fato é o volume do celular q é mais alto, acredito que seja a segunda opção,

[@HugoCostaItz]

Use a extensão Enhancer for KZbin™, ele possui um amplificador de áudio, além de outros recursos, uso sempre quando assisto vídeos com áudios baixos.

[@programan6391]

Tutorial de configuração do workspace por favor

[@codeshowbr]

valeu pela sugestão, vou preparar.

[@programan6391]

@@codeshowbr

[@rcamis]

Caraca isso é top demais

[@Dev.IagoMendes]

Qual distro + D.E tá usando?

[@rochacbruno]

Arch Linux (EndeavourOS) + KDE Plasma 6

[@gabrielsousa1585]

PHP tem o composer bem antes do cargo

[@codeshowbr]

acho que o Cargo inclusive foi inspirado no composer

[@Pensamentos-g7t]

8:29

[@brunodantas]

O áudio do vídeo ficou bem baixo. Se puder subir ele novo, vai ficar melhor! Pegando o equivalente em C#, o "uv int" é equivalente "dotnet new" 🙂

[@codeshowbr]

vou arrumar para os próximos, não tem como subir de novo :)

[@Dreaming-11]

Mas o UV não suporta pacotes CONDA, certo? Logo acho que a ferramenta mais geral no momento é o PIXI (que usa o UV para pacotes do PYPI).

[@g3nsfer]

Obrigado pela dica. Como você monta um ambiente Anaconda para ciência de dados com PIXI? Existe documentação para isso? Igual o Conda faz.

[@LgbtqiapnDudu]

Maven tá aí tem uns bons 15 anos e não aproveitaram o conhecimento. Alem de outros como Nvm, Composer, até o RubyGems. É uma pena o Python até hoje ter um problema tão básico.

[@IvoReali]

Conteúdo 10, didática: 11

[@jsbueno]

Hahaha.,,,eu também chamo de "ultra violento"

[@debaixodobrasil]

Python é o canivete suíço das langs

[@franciscobneto]

jurava que era o gabs ferreira

[@jlx8439]

o uv é realmente incrível, eu só fico triste pq lembro do video do anthony do flake8, e do fato de que a astral ta basicamente capitalizando em cima do trabalho de anos da comunidade python :/

[@rochacbruno]

Acho que isso é inevitável, open-source é um modelo de negócios, aliás nasceu para isso, eu compartilho da preocupação mas nesse ponto acho que por enquanto é um ganha-ganha, o UV tem licenças Apache + MIT, a comunidade toda vai se beneficiar de uma ferramenta que resolve problemas sérios do Python, se a empresa fizer mal a comunidade vai forkar e vida que segue. Eu vi o video do flake na época e sinceramente achei exagerado, no dia que vc coloca um código open-source no mundo vc está sujeito a isso.

[@allainclair]

uv tá muito bom mesmo

[@thiagomagalhaes3316]

Estilão do node/deno/rust

[@vitorsilva-or1dj]

Tema do shell bonito, qual seria?

[@codeshowbr]

Solarized-light em tudo! + starship no shell, meus olhos não aguentam mais usar dark mode :)

[@jorge.barcelos]

Pensei que o calcanhar de Aquiles do Python era a velocidade

[@rochacbruno]

A velocidade para 99% dos casos foi resolvida no Python 3.12 e vai melhorar ainda mais no 3.13, para os outros 1% dos casos ainda vai dar para usar sub-interpretradores, rodar sem a GIL, integrar com Rust ( caso do UV, Ruff, Polars) ou mudar para outra linguagem tipo Rust ou Go, mas esse 1% é bem raro,

[@TheMathues123]

E por que seria a velocidade ? Porque você ouviu alguém dizendo que python é lento você passou a achar isso ? Tu sabe que python é um front end pra c, c++ e fortran, né? Você acha essas liguagens lentas ? Se tu ta 1000km/h e eu estou a 500km/h eu sou lento ? Lógico que não, 500km/h é muito rápido!! Mas vai ter besta na internet falando que 500km/h é lento.

[@konoko-o3o]

​​@@TheMathues123 Isso que você disse não é 100% acurado, coloca uma api backend rodando em Python em um GCP Cloud Run onde tempo da execução e inicialização impacta significativamente no preço mensal da infraestrutura e você vai ver como isso faz diferença, Python não é uma linguagem lenta, mas colocando lado a lado a uma linguagem gerenciada como C#/Java ou especialmente compiladas para distribuição como Go e Rust e você consegue nitidamente ver o impacto da linguagem, no final nós fazemos todo tipo de bruxaria para atingir um custo razoável com projetos Python em cloud, não é atoa que raramente um projeto Python é feito deployment "in natura" sem uma parafernália em volta. Claro que isso melhorou muito com os anos, mas ele ainda vai perder para essas alternativas, em especial quando estamos falando de infra sob demanda.

[@TheMathues123]

@@konoko-o3o Ai vai dos lideres decidirem, usar python que ja é muito madura, muito bem resolvida e extremamente produtiva ou essas outras linguagens com pouquissima mão de obra extremamente experiente

[@manus7013]

Oque vão mudar aquela sintaxe lixo?

[@rochacbruno]

ahh isso já resolveram, você pode agora escrever no estilo C só colocar um `from ___future___ import braces` no topo do arquivo :)

[@manus7013]

@@rochacbruno muito obrigado pela informação amigo.

[@leosmi1]

como ele instala as dependências tão rápido???

[@rochacbruno]

Rust + Algoritmo de resolução + Cache

[@pedrovunana6626]

A única coisa que faltava e me dava imensa preguiça para começar a desenvolver bravamente em Python 🤩🤩🤩🤩

[@alisonalmeida8499]

Pessoal nao conhece virtualenv aqui, rsts

[@preystation6870]

Python não tem mesmo padronização, fato...

[@Cirleno]

Revolução, tu está de brincadeira né. rsrsr

[@codeshowbr]

Tem alguns anos que to tentando escrever o plugin "cargo take --means-of-productions"

[@brunomsantiago]

Coisa linda essa uv

[@littleghoost]

Por isso eu amo Rust.

[@luizAugustoll]

Eu não sou muito chato com filosofia KISS, mas não sei dizer se seria problema de python em si, já que python não é um framework e sim uma linguagem de programação.

[@rochacbruno]

Python não é apenas uma linguagem de programação, a PLR é a especificação da linguagem e tem várias implementações, quando falamos de Python, estamos geralmente nos referindo ao Cpython, não só a linguagem mas também todo seu ecossistema de ferramentas e padrões. É uma plataforma.

[@luizAugustoll]

@@rochacbruno ok

[@yuuta6118]

Vídeo novo 🎉

[@rcamis]

Mto bom

[@romulocollopy4974]

cargo new --with-coffee revolution!

[@rubempacelli6815]

Sinceramente, eu não vi qualquer motivo para do poetry pro uv.

[@yungpedrx7847]

Qual o problema?

[@rochacbruno]

0:00

[@carloskvasir]

Python em toda industria? Pareceu torcedor.

[@rochacbruno]

Python é importante em toda a industria de software, todo o ecossistema de AI e Dados está baseado em Python, aliás, esse comentário aqui está sendo postado com Python

[@carloskvasir]

@@rochacbruno eu vejo muito uso nessas área e também pra quem quer fazer automatizações nas outras áreas não.

[@rochacbruno]

@@carloskvasir Qual é a area que não usa dados e IA ou automações?

[@alex-cd1vq]

@@carloskvasir Como não?

[@Lindembergz]

UFA... ainda bem que não estudei python por 20 anos pra esperar isso acontecer kkkkkkkkkkkkkkkkk

[@codeshowbr]

UFA! Ainda bem!

[@pdrferrari]

muito difícil eu sair do poetry

[@rochacbruno]

Enquanto estiver funcionando bem para seu caso de uso não tem pq sair.

[@programe.python]

Poetry nao é o melhor mais?

[@leandroimail]

Maior problema do Python é o GIL, essa ainda não teve solução

[@codeshowbr]

PEP 703 - Python 3.13

[@christianlinux8283]

achei que ia falar do hatch, muito triste

[@rochacbruno]

Eu tinha colocado no meu script abordar os diferentes backends de build, porém não daria tempo, é só customizar no pyproject para usar o hatchling que o uv faz o resto.

[@christianlinux8283]

@@rochacbruno muito massa

[@joseluismartins8340]

Fántastico

[@Alexandrebluenote]

Revolução? Yikes.

[@rochacbruno]

Sim camarada! tem muitas revoluções ainda por acontecer

[@WillianCRBR]

Legal o vídeo. Tentei brincar de advinhar o que era o maior problema do python, antes de você mencionar. Achei que iria falar sobre a orientação a objeto porca dele. hehe Mas bacana, gerenciar dependencia de pacote no python é um caos também.

[@rochacbruno]

O que exatamente vc considera ruim na orientação a objetos do Python?

[@yeshua762]

@@WillianCRBR não entendi essa do "orientação a objetos porca", referente ao python, pode ser mais claro?

[@WillianCRBR]

Me refiro a gambiarra que a linguagem faz, pra utilizar herança e poliformismo. 1 - não ter interface. 2 - não ter modificadores de acesso (public, private, protected) 3 - não ter sobrecarga de método. E por aí vai... Eu sei que tudo isso, tem seu jeito de contornar no python. Mas na minha opnião, é bem ruim. Parece invenção da roda.

[@rochacbruno]

@@WillianCRBR Python não tem interface pois é Protocol based, tem protocolos estruturais, modificadores de acesso podem ser implementados com properties, sobrecarga de métodos nem faz sentido em linguagens sem static dispatch, Python é uma linguagem dinâmica, tem dynamic dispatch com o decorator @overload mas não tem razão de ter static dispatch, isso se resolve com o polimorfismo intrinseco da linguagem, Python usa Duck Typing, Monkey Patching, não é reinventar a roda, é outra abordagem, não faz sentido comprar a O.O que você aprendeu com uma linguagem estática em uma linguagem dinâmica.

[@WillianCRBR]

@@rochacbruno vc descreveu, exatamente porque eu acho ruim as formas que o python faz pra contornar. E discordo que o motivo disso, é por ser uma linguagem de tipagem dinâmica, pois outras também são, e utilizam o conceito de interfaces, modificadores de acesso e etc. PHP, Dart, typescript ( sendo possível usar tipagem dinâmica com any). Mas eu não quero impor o que eu acho não pessoal, é só minha opinião que acho ruim. Acho python incrível, pra projetos pequenos e simples. Tenho redes neurais que uso nele, webscrappers, modelos LLM rodando. Porém quando vc trabalha com um projeto mais robusto e tenta aplicar arquitetura de software nele, é eu acho ruim. E vc precisa contornar muita coisa pra usar DDD, Clean ou hexagonal architecture. Mas é só minha opinião, trabalhei com bastante linguagem, e achei ruim quando vc tem um projeto grande, com bastante regra de negócio e vc precisa abstrair em alguma arquitetura

[@cslemess]

Bigode == Rust Dev

[@adaum79]

Foi só ir morar em Portugal que o Bruno já ficou com cara de português 😂

[@codeshowbr]

@adaum79 Faz parte do processo de pedido de cidadania, se for lá com cara de português eles aprovam mais facilmente haha

[@m.araujo3428]

Muito baixo o som... :(

[@Cantor.Onival]

@@m.araujo3428 Why?😁 Tá normal!

[@digao3429]

como chamo o Uvicorn agr?? kkkkk

[@codeshowbr]

Unicórnio Ultra Violento

[@joaomauriciopereira184]

ainda prefiro php

[@rochacbruno]

PHP é muito bom também! mas PHP não resolve a questão de gestão de dependências em Python.

[@gabrielmengassodefranca1615]

só eu q acho estranho essa logo desse canal?????? me lembra outra coisa.....

[@codeshowbr]

lembra o que? é um C e um S de Code Show, o que isso lembra?

[@FodaseGoogreorio-h7v]

My name is Show, Code Show.

[@marcoslima7477]

@@codeshowbr Lembra SS. Tive a mesma sensação. rsrs

[@gabrielmengassodefranca1615]

@@codeshowbr lembra a logo do exercito nazista sdsjkdsadasdas

[@leanio21]

mário

[@codeshowbr]

que Mario? 😁

[@rochacbruno]

Aquele que te mostra o Python atrás do armário.

[@Raffa064]

cade a nilce?

[@aleph_zero]

@@Raffa064 Nunca saberemos. Mas o cabeçulinha do Pythonverso tá firme e forte.

[@j0584924]

@@Raffa064 😂😂😂😂

[@luizpbraga]

Doido como Python e forte no mercado mesmo tento uma gestão de dependências nojenta.

[@arthur8590]

@@luizpbraga vai por mim o python pelo menos tem uma gestão de dependências melhor que o JS, pelo menos tive bem menos problema com python

[@luizpbraga]

@@arthur8590 node p mim eh triste dms

[@DougLopes]

O maior problema do python é o log de erros que é um LIXO. Nunca vi um log de erros tão grande e ao mesmo tempo tão inútil. E fica ainda mais evidente o quão falho é o log de erros do python se comparar com uma linguagem que tu cita no video que é o rust, que não só tem uma mensagem concisa como até recomenda como resolver o problema.

[@codeshowbr]

As mensagens de traceback do Python estão melhorando (inspirado no Rust) agora no 3.13 já está bem melhor e no 3.14 terá mais melhorias.

[@DougLopes]

@@codeshowbr Vou dar uma testada na 3.13 pra ver então. Tentei instalar essa versão com o uv mas tava crashando o script de criar projeto do crewai. Tomara que melhore pq quando tive que usar python por 1 mês pra um projeto simplesmente passei muita raiva vindo do php e js, tá doido.

[@tiolv1174]