Responder: A familiar HTTP Service Framework • Hacker News Board

Re: Responder: A familiar HTTP Service Framework

#51

Post by basil-rash » Wed, Oct 17, 2018, 3:54 AM UTC

paultopia wrote: post #46

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…

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…

I use "short scripts" to mean: I have an idea I want to play around with, usually involving data analysis or some data structure or algorithm sketch, and I'd like to devote the next 2-3 hours to writing a 100-200 line program that evolves with me as I refine what exactly it is that I would like to be examining.

Re: Responder: A familiar HTTP Service Framework

#52

Post by amorphic » Wed, Oct 17, 2018, 3:54 AM UTC

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.

Andrew gave a great talk on this very topic at PyCon AU in August. Still at the formative stages it seems...

https://www.youtube.com/watch?v=-7taKQnndfo

Re: Responder: A familiar HTTP Service Framework

#53

Post by androidgirl » Wed, Oct 17, 2018, 3:58 AM UTC

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 it, and honestly it's fine for most cases, but it's pretty slow compared to just plain virtualenv. Considering virtualenv is prefectly fine I eventually switched back.

Re: Responder: A familiar HTTP Service Framework

#54

Post by viraptor » Wed, Oct 17, 2018, 4:00 AM UTC

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.

Can you though? There's likely a correlation between the codebase size and how experienced people work on it. If you have a beginner, they're both unlikely to work on a large project and unlikely to create their own framework. And to connect the last bit - the larger project becomes, the more likely it is you'll find some bloat in it. So the custom-framework : bloated-codebase relation becomes a bit of self fulfilling prophecy.

Re: Responder: A familiar HTTP Service Framework

#55

Post by keredson » Wed, Oct 17, 2018, 4:08 AM UTC

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…

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

Re: Responder: A familiar HTTP Service Framework

#56

Post by kungtotte » Wed, Oct 17, 2018, 4:13 AM UTC

paultopia wrote: post #46

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…

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…

I agree with you. Automate some task? Scrape some web content? Glue some programs together by translating the output of one to fit the input of the other?

Python it is! If it doesn't already have something in the standard library for your task, it's definitely in the PyPI. This reduces your work to importing a library and writing 5-20 lines of code.

Re: Responder: A familiar HTTP Service Framework

#57

Post by ryl00 » Wed, Oct 17, 2018, 4:25 AM UTC

paultopia wrote: post #46

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…

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

Re: Responder: A familiar HTTP Service Framework

#58

Post by basil-rash » Wed, Oct 17, 2018, 4:30 AM UTC

jnwatson wrote: post #45

basil-rash wrote: post #17

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.

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

Initial thoughts from looking through https://docs.python.org/3/library/typing.html#:

1. Love that it doesn't use structural typing, NewType seems great.

2. The syntax is bad. Maybe this is a "it just takes getting used to" thing, but I actually find it really bad. In TS, the syntax for typing almost always directly matches the syntax for the rest of the language. In Python, its a weird sort of LISPy DSL think that they made... compare:

  Py: Callable[[List[Tuple[int, string]], Dict[string, string]], int]
  TS: ([number, string][], { [key: string]: string }) => int

This only gets worse as you chain callables together, whereas in TS everything left-associates as you'd expect and it all works out nicely.

3. Admittedly, the TS dict syntax isn't beautiful, but it becomes very helpful for things like `{ [K in keyof T]: K extends number ? T[K] : never }`, which does not seem to be possible in Py.

4. Related to 3, but no never type? I see NoReturn, but it does not seem to actually cause any errors when you try to assign it to a variable. See below.

5. Type narrowing... does it exist? Seemingly not, see below.

6. Literals as types (enums)?

7. Generics, do I really need to pass in the internal representation of the type I'd like to use? That seems absurd. Will bad things happen if these internal identifiers collide? (Reference: `T = Generic('T')` creates a generic type)

Demo code that should throw an error at the assertUnreachable and nowhere else, but actually throws errors everywhere but the assert unreachable (types seemingly aren't narrowed by `type() == ...` checks):

  def foo(x: Union[str, int, float]):
    if (type(x) == int):
        return x / 3
    if (type(x) == str):
        return x.upper()

    return assertUnreachable()


  def assertUnreachable() -> NoReturn:
    raise RuntimeError('no way')

(this is all checked using mypy, v. 0.641)

Re: Responder: A familiar HTTP Service Framework

#59

Post by talltimtom » Wed, Oct 17, 2018, 4:50 AM UTC

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.

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 mypy, but as you say you’re not using that). At the end of the day you are using python and there must be a better way! though just like anything else you need to dedicate time to lean not just the syntax but also how to effectively use the language without needlessly over complicating things.

Re: Responder: A familiar HTTP Service Framework

#60

Post by daenz » Wed, Oct 17, 2018, 4:52 AM UTC

>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 for people to use, complete with its own logo and testimonials(???), it really presents itself as yet another soon-to-be unsupported and unmaintained/discarded project. We have to judge it based on how its presented, and in my humble opinion, it's being presented as The Hot New Shit, when it's maybe 300 original lines on top of massive existing frameworks.