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!
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
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.
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.
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! 😄👍
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
Ó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...
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.
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
@@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. 😉
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?
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.
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! 😉
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?
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.
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.
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
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,
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
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...
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.
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,
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.
@@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.
@@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
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 :/
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.
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
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.
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.
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.
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.
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.
@@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.
@@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
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 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.
![กี่หมื่นฟ้า | Your Sky Series EP.1 [1/4]](http://i.ytimg.com/vi/vLGjxFL6U_I/mqdefault.jpg)
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!
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
Eu tava vindo aqui falar que oque eu mais odeio em Python e o GIL hahaha
Eu tbm kkkk
Muito interessante. Eu como iniciante, sempre fico confuso e tentando o melhor caminho para iniciar um projeto e gerenciar.
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.
@@eu_danielbraga agora tu sabe que não tinha jeito melhor. Era o que tinha na cabeça da galera hahhaha. É.bom ter uma referência
Coitados dos iniciantes na tua mão😂
vc come iniciante?
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.
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
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! 😄👍
Quem sofre com resolver dependência no python, não queira chegar perto de Java.
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
Podo dia um inferno com MAVEN :D
Achei top essa ferramenta. Obrigado por compartilhar!
Bruno, como sempre EXCELENTE conteudo e MUITO didatico. Parabens.
Infelizmente nesse ramo toda suposta boa ideia precisa passar pelo teste do tempo. Veremos.
Boa. Muito legais seus vídeos cara!
eu que pensei que só existia o pip para gerencia de pacotes no pythom agora só usar UV coisa boa obrigado por essa perola
Muito bom Bruno! 👏🏻👏🏻
Ó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...
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.
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
@@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. 😉
NodeJS é muito pior kkkk já tentou resolver conflitos num projeto com 20+ dependências? Kkk
Que python vcs tão usando? As minhas imagens não passam de 500Mb.
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?
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.
gostei muito dessa solução, mas qual seria o diferencial dessa ferramenta, ao poetry? vejo o mesmo potencial, e já esta estabilizada no mercado
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,
@@rochacbruno gostei, vou dar uma chance!
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! 😉
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?
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.
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.
O projeto é aberto, a qualquer momento pode rolar um fork se acontecer o que aconteceu com TErraform e REdis
Se já existisse desde o começo ninguém nem ia notar; vê o Cargo por exemplo, tá lá, todo mundo usa e pronto
fica tranquilo, irá aparece outra ferramente em pelo meno 1 ano, isto sim enfraquece o python
@@RodrigoPinheiroMatias Se os mesmos padrões definidos nas PEPs forem mantidos eu não vejo problemas em mudar de ferramentas
É código livre, a gente faz fork 🤗
+1 que achou que era um vídeo sobre o GIL! 🤣 . Mas sinceramente, gostei de saber disso... vou testar! Ótimo vídeo!
Eu acho o uv muito top. Tenho usado direto.
Sensacional!
Muito bom, tava faltando isso mesmo em python
Estava usando poetry, e me incomodava com algumas coisas. Sensacional o uv, vou testar.
Conteúdo 10, didática: 11
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
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
Muito bom esse video...
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,
Use a extensão Enhancer for TH-cam™, ele possui um amplificador de áudio, além de outros recursos, uso sempre quando assisto vídeos com áudios baixos.
Bruno, bons olh's o vejam Obrigad' per tares de volta.
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
Rust tem boa gestão de memória e de concorrência portanto isso impacta sim na performance do algoritmo
Muito bom!!! =)
PHP tem o composer bem antes do cargo
acho que o Cargo inclusive foi inspirado no composer
Sentindo falta de mais vídeos seu de Rust.
Dê a ordem, camarada
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).
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.
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" 🙂
vou arrumar para os próximos, não tem como subir de novo :)
Python é o canivete suíço das langs
Muito bom o video. Bruno o som ficou bem baixo, não sei se o mic está muito longe ou embutido na câmera.
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...
@@codeshowbr é ai fica complicado rsrs, sem problema, ainda da para pegar o conteudo q é o importante.
8:29
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.
Caraca isso é top demais
uv tá muito bom mesmo
Bruno, vc ainda mantém a dynaconf?
sim! atualmente trabalhando no type system para a versão 4.0
@@codeshowbr Adorei o Dynaconf. Queria muito ter experiência para contribuir com o projeto. Parabéns!
Ja tem pra windows??
tem sim, de acordo com as docs funciona em Mac, windows e Linux
Achei engraçado alguém do Ruim perguntar se tem a sua plataforma
Tem sim!
Se tu usa o scoop: scoop install uv
Se tu usa o winget: winget install --id=astral-sh.uv -e
como ele instala as dependências tão rápido???
Rust + Algoritmo de resolução + Cache
Python não tem mesmo padronização, fato...
Qual distro + D.E tá usando?
Arch Linux (EndeavourOS) + KDE Plasma 6
Pensei que o calcanhar de Aquiles do Python era a velocidade
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,
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.
@@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.
@@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
A única coisa que faltava e me dava imensa preguiça para começar a desenvolver bravamente em Python 🤩🤩🤩🤩
jurava que era o gabs ferreira
Gostaria de ver um projeto utilizando workspace
Hahaha.,,,eu também chamo de "ultra violento"
Estilão do node/deno/rust
Tutorial de configuração do workspace por favor
valeu pela sugestão, vou preparar.
@@codeshowbr
Coisa linda essa uv
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 :/
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.
Pessoal nao conhece virtualenv aqui, rsts
Revolução, tu está de brincadeira né. rsrsr
Tem alguns anos que to tentando escrever o plugin "cargo take --means-of-productions"
cargo new --with-coffee revolution!
Oque vão mudar aquela sintaxe lixo?
ahh isso já resolveram, você pode agora escrever no estilo C só colocar um `from ___future___ import braces` no topo do arquivo :)
@@rochacbruno muito obrigado pela informação amigo.
Por isso eu amo Rust.
Sinceramente, eu não vi qualquer motivo para do poetry pro uv.
Python em toda industria? Pareceu torcedor.
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
@@rochacbruno eu vejo muito uso nessas área e também pra quem quer fazer automatizações nas outras áreas não.
@@carloskvasir Qual é a area que não usa dados e IA ou automações?
@@carloskvasir Como não?
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.
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.
@@rochacbruno ok
Maior problema do Python é o GIL, essa ainda não teve solução
PEP 703 - Python 3.13
Vídeo novo 🎉
UFA... ainda bem que não estudei python por 20 anos pra esperar isso acontecer kkkkkkkkkkkkkkkkk
UFA! Ainda bem!
Tema do shell bonito, qual seria?
Solarized-light em tudo! + starship no shell, meus olhos não aguentam mais usar dark mode :)
Qual o problema?
0:00
muito difícil eu sair do poetry
Enquanto estiver funcionando bem para seu caso de uso não tem pq sair.
Fántastico
Bigode == Rust Dev
Foi só ir morar em Portugal que o Bruno já ficou com cara de português 😂
@adaum79 Faz parte do processo de pedido de cidadania, se for lá com cara de português eles aprovam mais facilmente haha
Mto bom
Revolução? Yikes.
Sim camarada! tem muitas revoluções ainda por acontecer
achei que ia falar do hatch, muito triste
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.
@@rochacbruno muito massa
Poetry nao é o melhor mais?
como chamo o Uvicorn agr?? kkkkk
Unicórnio Ultra Violento
cade a nilce?
@@Raffa064 Nunca saberemos. Mas o cabeçulinha do Pythonverso tá firme e forte.
@@Raffa064 😂😂😂😂
Muito baixo o som... :(
@@m.araujo3428 Why?😁 Tá normal!
ainda prefiro php
PHP é muito bom também! mas PHP não resolve a questão de gestão de dependências em Python.
Doido como Python e forte no mercado mesmo tento uma gestão de dependências nojenta.
@@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
@@arthur8590 node p mim eh triste dms
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.
O que exatamente vc considera ruim na orientação a objetos do Python?
@@WillianCRBR não entendi essa do "orientação a objetos porca", referente ao python, pode ser mais claro?
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.
@@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.
@@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
só eu q acho estranho essa logo desse canal?????? me lembra outra coisa.....
lembra o que? é um C e um S de Code Show, o que isso lembra?
My name is Show, Code Show.
@@codeshowbr Lembra SS. Tive a mesma sensação. rsrs
@@codeshowbr lembra a logo do exercito nazista sdsjkdsadasdas
mário
que Mario? 😁
Aquele que te mostra o Python atrás do armário.
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.
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.
@@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.