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
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
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.
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! 😄👍
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.
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.
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. 😉
Ó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...
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.
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
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.
@@viniciusmorgado9722 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
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...
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! 😉
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 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.
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.
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.
