Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Responder: A familiar HTTP Service Framework

python-responder.org

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Responder: A familiar HTTP Service Framework

#31

Post by biggio »

m_ke wrote: post #4
monkmartinez wrote: post #2

Pretty cool, but I can't shake the feeling that the first example looks an awful lot like javascript... Perhaps... Maybe ... its because I have been "cheating" on Python with JS. I mean, it is a pain in the booty to code up a web app in python without JS. Try to code a mobile app with Python and Kivy... not all that fun (not practical). In less than a week with React, I have done both. So... why not just skip Python…

I'd argue that python needs an async django, which will hopefully be django in a few releases.

There are numerous async frameworks already, aiohttp to name one, in addition to others mentioned above.

Re: Responder: A familiar HTTP Service Framework

#32

Post by m_ke »

diminoten wrote: post #21
m_ke wrote: post #4

Earlier quoted context omitted.

I'd argue that python needs an async django, which will hopefully be django in a few releases.

Yeah I mean the async landscape for web frameworks isn't exactly as populated as the "yet another web framework" statement makes it seem. This is how we get to async Django, and I think that's part of why Tom Christie is helping out. I also doubt Reitz thinks this is the usurper of Django anyway. It's more than an experiment, but less than "the new One True Way". As for ASGI python web frameworks, there are no mature…

Async support is actually planned for django in upcoming releases. Here's some info about that https://www.aeracode.org/2018/06/04/django-async-roadmap/

From what I understand ASGI was developed by Andrew Godwin for Django Channels.

Re: Responder: A familiar HTTP Service Framework

#33

Post by vaughnegut »

weberc2 wrote: post #5
throwaway682888 wrote: post #3

Great, another issue tracker for Kenneth and his followers^H^H^H^H^H^H^H^H^H maintainers to belittle contributors, delete unfavorable comments and generally create a hostile environment for users. No thanks!

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

Re: Responder: A familiar HTTP Service Framework

#34

Post by m_ke »

scardine wrote: post #16
m_ke wrote: post #4

Earlier quoted context omitted.

I'd argue that python needs an async django, which will hopefully be django in a few releases.

There is an async Flask in the form of Sanic[1]. Looks quite usable compared to raw aiohttp or twisted spaghetti I had to help maintain a couple months ago. [1] https://sanic.readthedocs.io/en/latest/

We actually use Sanic alongside Django for some of our machine learning services. Has been working well so far.

Re: Responder: A familiar HTTP Service Framework

#35

Post by diminoten »

biggio wrote: post #28
diminoten wrote: post #23

Earlier quoted context omitted.

This is an insane notion, and I don't mean "insane" as a hyperbole, but literally not sane. Honestly, I very much doubt what you've written is even true, it's that nuts.

I would say I can predict with relative accuracy how bloated a codebase is by looking at how many custom frameworks I find at team member profiles.

The problem with this statement is that you're acting like everyone and their mother has a GitHub profile to begin with, and then that they've invariably got a "custom framework" there as well.

None of this meshes with any reality I'm aware of. I'm willing to be wrong here, but considering the statistics I know about hiring, GitHub recreational usage among the average software dev, and... I dunno, my own proclivity to write frameworks, your story is pretty far from believable.

Re: Responder: A familiar HTTP Service Framework

#36

Post by diminoten »

m_ke wrote: post #32
diminoten wrote: post #21

Earlier quoted context omitted.

Yeah I mean the async landscape for web frameworks isn't exactly as populated as the "yet another web framework" statement makes it seem. This is how we get to async Django, and I think that's part of why Tom Christie is helping out. I also doubt Reitz thinks this is the usurper of Django anyway. It's more than an experiment, but less than "the new One True Way". As for ASGI python web frameworks, there are no mature…

Async support is actually planned for django in upcoming releases. Here's some info about that https://www.aeracode.org/2018/06/04/django-async-roadmap/ From what I understand ASGI was developed by Andrew Godwin for Django Channels.

I'm super excited for that development work to begin!

But just thinking about my own experiences, being able to look at what other people have done so far with it would help immensely when building the nuts and the bolts of the feature. This project will help immensely with that.

Re: Responder: A familiar HTTP Service Framework

#37

Post by m_ke »

biggio wrote: post #31
m_ke wrote: post #4

Earlier quoted context omitted.

I'd argue that python needs an async django, which will hopefully be django in a few releases.

There are numerous async frameworks already, aiohttp to name one, in addition to others mentioned above.

I'm aware of all of the flask inspired async micro frameworks.

By django like I meant a batteries included framework with an integrated async ORM, auth, DRF and etc. From what I've seen we'll probably have to wait for django to get there, which might take a few years.

Re: Responder: A familiar HTTP Service Framework

#38

Post by darpa_escapee »

basil-rash wrote: post #13
monkmartinez wrote: post #2

Pretty cool, but I can't shake the feeling that the first example looks an awful lot like javascript... Perhaps... Maybe ... its because I have been "cheating" on Python with JS. I mean, it is a pain in the booty to code up a web app in python without JS. Try to code a mobile app with Python and Kivy... not all that fun (not practical). In less than a week with React, I have done both. So... why not just skip Python…

I've started to wonder what the place of Python is at all. Machine Learning has become deeply coupled with Python, so you have that side of things, but that's not my personal area of interest. People say that it's good for "short scripts", but whenever I decide to write something in Python instead of TS, I'm instantly met with so many runtime type errors that I wonder how people can honestly believe lack of static ty…

Python has an excellent ecosystem for those in the sciences, finance or those working with data. A few popular and mature web frameworks are written in Python. It has a place next to Bash et al when it comes to system scripting and acting as glue between different streams, utilities and resources.

Static analysis tooling is excellent and type annotations only aid their accuracy.

It's my impression that developers tend to learn to love static typing if they didn't cut their teeth on a statically typed platform. It takes experience to know that certain errors can be mitigated via language features and to know how annoying those errors are when they needlessly pop up.

Unenforced explicit typing was and is still a boon for Python. Typing is often lost on developers who are still in "Hello, world!" territory and scientists who are using it as an adjunct to MATLAB. It can be a hindrance to rapid development, as well.

Re: Responder: A familiar HTTP Service Framework

#39

Post by rtpg »

vaughnegut wrote: post #33
weberc2 wrote: post #5

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

I tried using it for a heroku app since it was recommended in the Python setup (I used a plain requirements.txt in other projects)

For me, it broke very often, would take forever to recalculate stuff, and would simply get in the way _way_ too much. I get the logic of the system but in practice pip + requirements.txt basically works for my use cases.

Post reply on HN