Live data from Hacker News

Responder: A familiar HTTP Service Framework

python-responder.org

101–110 of 116 posts

Re: Responder: A familiar HTTP Service Framework

#101

Earlier quoted context omitted.

Yeah, the speed thing with lockfiles is painful. But python dependency management is such a mess anyway that it's probably the best thing out there.

Consider https://github.com/sdispater/poetry as an alternative.

This looks really nice! That dependency example makes relying on pipenv seem kinda scary, and I really like how it replaces the setup.py too.

Re: Responder: A familiar HTTP Service Framework

#102

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...)?

[disclosure I am a sanic contributor] aiohttp is a great project, very similar to sanic, I'd say the big thing is sanic is slightly more flask like than aiohttp in ergonomics (which is something aiohttp has been working on[1]).

Sanic also makes performance a key development goal so you can feel comfortable the project will scale gracefully. But I will stress I don't have current benchmarks to compare against aiohttp

[1]https://aiohttp.readthedocs.io/en/stable/faq.html#id1

Re: Responder: A familiar HTTP Service Framework

#103
post #57

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).

And bash/zsh. Bash can be really powerful. Slow for some tasks though (much slower than perl for example), but little times I've had that problem.

Re: Responder: A familiar HTTP Service Framework

#104

Earlier quoted context omitted.

What's wrong with pipenv? I've been meaning to try it

So I've been using it a bunch on my more recent Python projects. The promise and the reality are unfortunately not close. For the record I love having a one stop tool for virtualenvs and dependency management. That's quite nice. The Pipfile is nice. The Pipfile.lock is awesome. The tool itself is: 1. Painfully slow. 2. Very buggy. For example `pipenv graph --json` is broken in the latest release. This is the mechanis…

Here's some sources. This bug in 2017 is characteristic "Pipenv Halloween easter egg" [0]. Pipenv has caused lots of unneeded drama in the Python community[1] - just search for past Pipenv posts.

Most of the criticism comes from software developers, and I suspect Pipenv fans are hobbyists (like fuck me for choosing Python in production, right?) I doubt Go's tooling accepts this strange behavior from the maintainers[2]. Kenneth Rietz is NOT a core Python developer.

So for my opinion, we have Pipenv instead of Requests support for async/futures, HTTP2.0, Websockets, or better encoding. But the documentation gets updates I see: "Requests is the only Non-GMO... organic, grass-fed HTTP/1.1 requests"[3]. This emojifuck for humans has no drive, so Go has better HTTP packages now.

Python's packaging has gotten political. I hate politics. I won't help new programmers with Pipenv, and I don't care if that's good or bad. At least Poetry _respects_ PEPs with it's well-defined specification. But I'm not gonna fight a losing battle. Maybe Pipenv gets ironed out one day. Hell, maybe Java replaces Maven. But I grow weary of immature repo maintainers. I just need working code; yet I feel this answers to nobody.

[0] https://github.com/pypa/pipenv/issues/786

[1] https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-l...

[2] https://github.com/pypa/pipenv/commit/fe78628903948013e8687d...

[3] http://docs.python-requests.org/en/master/

Re: Responder: A familiar HTTP Service Framework

#105

Earlier quoted context omitted.

In further reflection, it is perhaps only because I am so used to TS that I try to make as intense of refactorings as I do. A programmer who does not have prior experience working with as well tooled of a language would not be attempting the kinds of transformations I do, and thus may not experience as many issues.

It sounds like you should invest some time in learning to program python in a pythonic way. If you are trying to build stuff using tons of design patterns factory patterns, you are doing it wrong. Most of those where made to work around limitations of type-systems which aren’t there in python, and naturally you end up having issues solving things like that when you don’t have typing. (Which you do still have with myp…

I'm not trying to build using tons of factory patterns or the like, quite the opposite actually. I try to code as close to the bare language as possible, and work under the assumption that if I at some point would like to pivot my reasoning or approach to a program, the language and the tooling available will help me do so. This is simply not true without types.

I'm not alone in thinking that, the creator of Python himself has devoted his recent work to adding types to Python. Is that just because he doesn't write his code "the correct way"? Does he simply know the syntax but not hoe to effectively use the language? I don't think so.

Re: Responder: A familiar HTTP Service Framework

#106
> Background tasks, spawned off in a ThreadPoolExecutor.

This could be very nice; something that I've often found clunky when building a prototype is the amount of infrastructure required to get a more full-featured task queue up and running (say Celery or RQ). You can always just run an event loop, but then you have to reinvent a lot of the nice delay/scheduling machinery.

Re: Responder: A familiar HTTP Service Framework

#107
post #93
post #78

Earlier quoted context omitted.

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.

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 thing since sliced bread regardless. I have legitimate support concerns before I would even consider using this for something real, and I've had two responses so far that address them by merely invoking his name. What a sad place to be in.

Re: Responder: A familiar HTTP Service Framework

#108

Earlier quoted context omitted.

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…

it's the quality of the libraries above all else that keeps me coming back to python. truly world class.

Shout out to Django!

Re: Responder: A familiar HTTP Service Framework

#109

Earlier quoted context omitted.

Regarding #2, the python code has the arguable advantage that (with appropriate variables in scope) it's valid standard python code[0] that could evaluate to (a representation of) the desired type, whereas the typescript isn't valid javascript code, and I don't think it's a valid (value-level) typescript expression either. 3 and 4 are disappointing though. 0: I'm assuming the extra [ after Callable is a typo.

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.

  Server = Tuple[Address,ConnectionOptions] # array subscipt might not the best choice here, but it works
  UserId = NewType('UserId',int) # ordinary function call
  Scalar = int | str # could be equivalent to Union[int,str] with appropriate value of Type.__or__
0: for example:

  def intBit(N):
    if N==0: return type(None)
    if N==1: return Bool
    if N>INT_WIDTH: return long
    return int

Re: Responder: A familiar HTTP Service Framework

#110

Earlier quoted context omitted.

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…

it's the quality of the libraries above all else that keeps me coming back to python. truly world class.

Don't forget the community and the support for those libraries. It's extremely welcoming and newbie-friendly.
Post reply on HN