Na época em que surgiu o SSR era a abordagem comum e quase não existia API REST e PHP era a linguagem lider de mercado, portanto no webpy o ponto mais forte era justamente a linguagem de template.
Que tentava imitar um pouco do que se via em PHP
Talvez esse tenha sido o motivo do webpy ter sido duramente criticado, o foco era grande em sua linguagem de template, gerando este tipo de discussão:
E olha só quem deu sua opinião Armin, o criador do Flask, 4 anos antes de criar o Flask e 2 anos antes de criar o Jinja
O webpy foi inspirado no Sinatra/Ruby e continua em desenvolvimento hoje em dia mantendo as mesmas premissas github.com/webpy/webpy porém não enquadra o ranking dos principais frameworks Python
Mas é notavel a influência dele em frameworks que surgiram depois como o Bottle (que foi derivado direto do webpy e inclusive tendo core devs do Reddit como um dos primeiros contribuidores)
Ironicamente o Flask (chamado de Denied), surgiu como uma piada para satirizar o Bottle e Sinatra, mas a piada fez sucesso e acabou virando um dos principais frameworks.
Além disso podemos notar que o Flask, framework que ajudou a popularizar o estilo que hoje é adotado por @FastAPI entre outros, foi ispirado pelas ideias do webpy entre outros como o cherrypy.dev que inclusive completou 20 anos de existência e ainda é mantido.
“[Webpy inspired the] web framework we use at FriendFeed [and] the webapp framework that ships with App Engine…”* — Brett Taylor, co-founder of FriendFeed and original tech lead on Google App Engine
O do FriendFeed (comprado pelo Facebook) era o tornadoweb.org
A história dos frameworks web em Python é cheia de curiosidades:
- O primeiro micro framework que surgiu se chamava "bobo"
- O Django surgiu de um CMS (e vontade dos devs de deixar o PHP)
- O Pyramid é a fusão entre Pylons e Turbogears/Repoze
- O Zope ...
- O Zope já foi o framework/plataforma mais importante do ecossitema web Python e há 20 anos já tinha conceitos de typing e interfaces
- O Zope tinha um banco de dados próprio que botava medo pelo fato de poucas pessoas saberem manter aquilo.
- O web2py (não confundir com webpy) passou de hype, para vencedor de premios, framework mais amado, para framework mais odiado devido a inumeras criticas de devs Python "famosos" e por fim acabou no quase esquecimento
Essa evolução de 20 e poucos anos de Python para web nos trouxe ao cenário atual:
- Django é o lider de mercado
- FastAPI é o mais moderno e promissor
Será que dá para prever o que vem por ai para os próximos 10 anos?
Percebi que grande parte dos projetos que usa versões x.y.z não segue de verdade o versionamento semântico.
Dá trabalho sim, mas é possível fazer múltiplos releases e em ordem cronológicas completamente distintas, e o mais importante: manter a compatibilidade reversa.
🧵
Versão inicial 0.1.0
Na branch main:
- Nova feature super legal
- Outra feature nova que ainda precisa de mais testes
- Bugfix que não influencia na experiência de uso
- Bugfix que altera parametros de função
- Security patch
- Disable a magic function
+ backlog enorme.
🧵
Não precisa ficar esperando o backlog estar todo resolvido ou a branch main estar toda estável para fazer um release 0.2.0.
Mesmo as linguagens mais simples como Python ainda tem um nível de complexidade que não condiz com o objetivo de um teste.
Testes deveriam ser declarados e não programados.
A area de automação de testes é onde low-code e no-code deveria reinar e eu mesmo tendo trabalhado durante quase 5 anos como Engenheiro de Qualidade de Software não entendo o motivo de se investir tanto em contratar Devs e Ops para escrever testes.
O profissional de Qualidade deveria focar em entender as funcionalidades do produto, comunicar-se com os envolvidos, sugerir melhorias e não em aprender linguagens, ferramentas e ambientes para rodar os testes.
Você usa `print` do #python para depurar durante o desenvolvimento?
Mesmo com vários tipos de debuggers disponíveis e o novo `breakpoint` do Python 3.7, na maioria das vezes um simples `print` é mais fácil para inspecionar uma variavél no Python.
Dá para deixar isso melhor 🧵
Primeiro um exemplo do uso do print nativo do python para debugar objetos complexos.
Como dá para perceber o output não é tão amigável de inspecionar.
Dá para deixar isso melhor usando `debug` no lugar de `print`
Porém Python não tem essa função debug nativa, você vai precisar **hackear** seu Python local para adicionar a função debug.