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

41–50 of 116 posts

Re: Responder: A familiar HTTP Service Framework

#41

Post by joshgachnang »

basil-rash wrote: post #15
biggio wrote: post #12

I used to hire people who have created their own frameworks like this one and our codebase were so bloated. At one point I had to let people go and spend the next year removing tens of thousands of lines of useless nonsense. Since that lesson, I look at candidates Github and if I see a custom built framework, I pass, regardless of how good they performed.

You can do that if you want... but it seems a bit extreme to rule out a candidate based on one project that could be really quite well designed and useful for whatever community it aims to benefit.

Especially considering there's a big difference between what people work on for fun/publish to Github and what they'd consider using in a workplace environment.

Re: Responder: A familiar HTTP Service Framework

#42

Post by keredson »

biggio wrote: post #12

I used to hire people who have created their own frameworks like this one and our codebase were so bloated. At one point I had to let people go and spend the next year removing tens of thousands of lines of useless nonsense. Since that lesson, I look at candidates Github and if I see a custom built framework, I pass, regardless of how good they performed.

There are definitely people who create frameworks who shouldn't, out of wanting to be "the guy", or not wanting to learn existing tooling. But frameworks/libraries are code too. SOMEONE has to write them. And sometimes there are genuinely good/unique ideas. It's good that strong coders w/ genuine knowledge of the problem domain tackle them. Your statement is equivalent to "I've read bad books, therefore I'd never hire an author."

Re: Responder: A familiar HTTP Service Framework

#44

Post by meddlepal »

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

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 mechanism that other tools use to hook into pipenv. It's actually been broken in various ways since May.

It's also incompatible in subtle ways with the latest pip. So I had to downgrade to pip 10.x.

I've had some frustrating experiences lately now that the honeymoon is over.

I'm going to keep using it, but I really hope some serious improvement is made in the next 6 to 12 months around performance and stability.

Re: Responder: A familiar HTTP Service Framework

#45

Post by jnwatson »

basil-rash wrote: post #17
basil-rash wrote: post #13

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…

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.

You need `import typing`, and an editor with integrated mypy (e.g. vim). It is almost as good as static typing.

Re: Responder: A familiar HTTP Service Framework

#46

Post by paultopia »

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…

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 manipulations. (And data sciencey stuff of course.)

Re: Responder: A familiar HTTP Service Framework

#47

Post by paultopia »

biggio wrote: post #12

I used to hire people who have created their own frameworks like this one and our codebase were so bloated. At one point I had to let people go and spend the next year removing tens of thousands of lines of useless nonsense. Since that lesson, I look at candidates Github and if I see a custom built framework, I pass, regardless of how good they performed.

But this is Kenneth Reitz. He's written multiple everyone on earth uses this-level libraries. Hardly likely to produce useless nonsense.

Re: Responder: A familiar HTTP Service Framework

#48

Post by androidgirl »

biggio wrote: post #12

I used to hire people who have created their own frameworks like this one and our codebase were so bloated. At one point I had to let people go and spend the next year removing tens of thousands of lines of useless nonsense. Since that lesson, I look at candidates Github and if I see a custom built framework, I pass, regardless of how good they performed.

I agree that might be a bit heavy handed, I personally like implementing frameworks or tools in new languages that I'm learning because it's fun and build familiarity. Production code is way different than that.

Re: Responder: A familiar HTTP Service Framework

#49

Post by paultopia »

meddlepal wrote: post #44
vaughnegut wrote: post #33

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…

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.

Re: Responder: A familiar HTTP Service Framework

#50

Post by amorphic »

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/

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

Post reply on HN