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

111–116 of 116 posts

Re: Responder: A familiar HTTP Service Framework

#111

Post by basil-rash »

a1369209993 wrote: post #109
basil-rash wrote: post #63

Earlier quoted context omitted.

Is there a utility to having your types and your values in the same namespace? The extra [ is not a typo, the syntax is: `Callable[[Arg1Type, Arg2Type], ReturnType]`. Or, if the arguments don't matter, `Callable[..., ReturnType]`, but this does not mean that the type is not a valid expression. Edit: I was missing a ] actually, separating the arguments from the return value.

> Is there a utility to having your types and your values in the same namespace? Well somewhat[0], but the main putative benefit would be having types be valid expressions in the target language, since you can do type-checking with function decorators, and generally interact with types useing the normal language mechanism for interacting with values, rather than some horrid bolted-on piece of crap like C++ templates.…

mypy's response to that code:

  error:invalid type comment or annotation
  note:Suggestion: use intBit[...] instead of intBit(...)
So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. This is probably the least "pythonic" implementation possible.

And even if the code were valid, it's relying on N being a statically known value, which is a bit off because sure, you could have N be some global const config variable, but it would be very weird for configuring the value of the variable to require you to also go into the code and change things around to work with bool's or None's instead of int's.

Re: Responder: A familiar HTTP Service Framework

#112

Post by kdmytro »

giancarlostoro wrote: post #87
amirathi wrote: post #83

Earlier quoted context omitted.

I understand the benefits of keeping front-end separate from back-end. - Separate teams working on front-end and back-end independently - Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?) - and much more Knowing all that, I chose to mix up VueJS with Django solely to optimise for speed in a single person company. Thanks to this setup, - Authentication…

> Authentication is handled via Django sessions (didn't have to spend time on JWT tokens) That's intriguing, wondered how that'd work out with a SPA. I'm not big on SPA's currently they only make sense for certain type of websites to me, don't mind them if they're done correctly though. But hey if what you've done works for you that's good to me, until I have to touch that code :) Hopefully it's not too awful, it jus…

Using Django sessions in an SPA is actually very easy. It just works, the browser handles the cookies for you. The only thing that developers has to do is to remember to include CSRF header with unsafe requests (such as PUT or POST), this is usually done by adding some kind of a pre-send hook in your request library of choice. There is a section in Django docs that explains how to do just this.

Re: Responder: A familiar HTTP Service Framework

#113

Post by scardine »

amorphic wrote: post #50
scardine wrote: post #16

Earlier quoted context omitted.

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/

I used aiohttp for a small project recently and found that it to be very good. Combined with aiohttp-json-rpc I had a very effective websocket-based JSON RPC backend service up and running in a very short time and with very little boilerplate. I'll be using this pattern again for sure. What would have been the advantage of me using Sanic instead (I haven't RTFM for sanic yet but I'm about to...)?

The thing I like about Django is that it is an opinionated framework so lots of decisions were already made for me. Flask is a not too distant second place.

With aiohttp you can make neat things it is operating a level below Sanic - in my experience people end up writing their own half-baked undocumented framework based on a combination of aiohttp, some ORM and a template engine - sometimes with half a dozen combinations in the same company.

Re: Responder: A familiar HTTP Service Framework

#114

Post by gigatexal »

daenz wrote: post #107
Perados wrote: post #93

Earlier quoted context omitted.

You really have no idea who Kenneth Reitz is, do you?

He wrote Requests. His many other side projects are not nearly adopted, supported, or maintained like Requests. This project will likely be the same as the vast majority of those other side projects. This cult of personality stuff is really bizarre though. I actually feel bad for Kenneth in this regard, since he'll never know if what he makes is actually any good, since his followers will tell him it's the greatest t…

Requests is a work of art. And the man is a self taught programmer. In that regard he can be my patron saint for that matter. How many of us have repos that we don’t maintain. He does this work for free. So if he wants to let something languish so be it. If you depend on a work he doesn’t upkeep then fork it and add to it.

Re: Responder: A familiar HTTP Service Framework

#115

Post by a1369209993 »

basil-rash wrote: post #111
a1369209993 wrote: post #109

Earlier quoted context omitted.

> Is there a utility to having your types and your values in the same namespace? Well somewhat[0], but the main putative benefit would be having types be valid expressions in the target language, since you can do type-checking with function decorators, and generally interact with types useing the normal language mechanism for interacting with values, rather than some horrid bolted-on piece of crap like C++ templates.…

mypy's response to that code: error:invalid type comment or annotation note:Suggestion: use intBit[...] instead of intBit(...) So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. This is probably the least "pythonic" implement…

> So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of.

Yeah, that sounds about par for the course for bolt-on static-y typing in languages that aren't supposed to be statically typed.

Re: Responder: A familiar HTTP Service Framework

#116

Post by basil-rash »

a1369209993 wrote: post #115
basil-rash wrote: post #111

Earlier quoted context omitted.

mypy's response to that code: error:invalid type comment or annotation note:Suggestion: use intBit[...] instead of intBit(...) So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. This is probably the least "pythonic" implement…

> So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. Yeah, that sounds about par for the course for bolt-on static-y typing in languages that aren't supposed to be statically typed.

At least we have TS.
Post reply on HN