91–100 of 116 posts
>The Python world certainly doesn't need more web frameworks. But, it does need more creativity. Then why create a "new python HTTP service framework"? The Flask and Falcon communities are very welcoming to creativity. This project strikes me as a fun side project that doesn't have serious legs or ambitions, which, don't get me wrong, is totally encouraged and fine! However, when it's being touted as a new framework…
> This project strikes me as a fun side project that doesn't have serious legs or ambitions And it totally is! "The primary goal here is to learn, not to get adoption" [1]. Kenneth Reitz is just another developer who created a public repo with some docs, a logo and the clear indication that it is just for fun. I don't see why everyone is so on the fence with this. [1] https://github.com/kennethreitz/responder#the-goa…
And Kenneth Reitz isn't "just another developer". He's well known, and isn't shy to mention his `requests` library ("uses the actual Requests you know and love").
Cynically, you might say the "just for learning" phrase is a great way of avoiding comparisons to existing frameworks initially. The thing is, it could compare favorably. For one thing, Flask and Falcon support/have to support (?) old Python versions - Falcon even says they support Python 2.6, which is ridiculous (EDIT: doesn't seem to be true from the tox file, but the website still claims it does). All that compatibility stuff provides zero value for new projects.
Background tasks are a great idea. Being a bit opinionated isn't necessarily a bad thing either; Flask would benefit hugely if they recommend people use app factories and blueprints from day 1. It adds almost no overhead, but makes building the application out much, much easier in the future.
Earlier quoted context omitted.
This is Kenneth Reitz, it’ll be supported.
Sorry, but invoking the name of someone who has many half-baked projects on their github (and again, that's totally fine), doesn't instill confidence in me to put my business's new product on it. There's nothing groundbreaking here. Innovation has to outweigh the lack of project maturity for serious people to use it in production, and the innovation just isn't here.
>The Python world certainly doesn't need more web frameworks. But, it does need more creativity. Then why create a "new python HTTP service framework"? The Flask and Falcon communities are very welcoming to creativity. This project strikes me as a fun side project that doesn't have serious legs or ambitions, which, don't get me wrong, is totally encouraged and fine! However, when it's being touted as a new framework…
Its not just another web framework, its another plea for approval.
Earlier quoted context omitted.
I wonder if you have a different definition of "short scripts" than many others. It seems to me that a genuinely short script wouldn't require big refactors, or types---that would be overkill for a short script. Personally, I use Python as a Bash replacement a lot, that's what I think of when I hear "short scripts." Sort of what people used to use Perl for. Pushing strings around, complicated repetitive filesystem ma…
> Sort of what people used to use Perl for. Used to? People still do this (I should know; I'm one of them).
As a very regular Requests user I'm pretty excited about Responder. There are times when I just want to stand up a 'glue' API, and this looks extremely convenient for that purpose. I've wasted too many hours futzing with flask+WSGI+nginx+ubuntu to want to stand up something with it on a whim.
What I really need is a python web framework that has first class support for serving SPA applications (VueJS, React etc). I spent quite a bit of time setting up my Django app to serve VueJS (replacing the built-in Jinja templates). Once ready, it became a powerful application with ORM, middleware and all other Django goodies coupled with modern JS framework on the frontend. I hear Rails 6 is going to support modern…
https://github.com/kennethreitz/responder/issues/53
I'll continue helping Kenneth with this, cause that's a pain point I also want to solve for myself.
On a related note, I tried to build something similar for Django in the past. (it worked, but it's somewhat under construction again due to changes in Django 2)
Earlier quoted context omitted.
I’ve got plenty of criticism for pipenv, but comments like these don’t endear me towards Kenneth’s critics.
What's wrong with pipenv? I've been meaning to try it
Earlier quoted context omitted.
I'd argue that python needs an async django, which will hopefully be django in a few releases.
Tornado[0] is not on per when it comes to features richness of Django. Yet, it's async and a joy to write. You should check it out if you have not. I would like to hear more from others about Tornado vs other Python frameworks as well. [0]: http://www.tornadoweb.org/en/stable/
It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.
Earlier quoted context omitted.
I'd argue that python needs an async django, which will hopefully be django in a few releases.
If you can manage with Flask there's Quart [1] [1] https://gitlab.com/pgjones/quart