8 ms·

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"

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 all together? I have been asking myself that question. Bottom line: The authors of this "service framework" states the Python world doesn't need another web framework, I agree. It needs some serious love in GUI land.

m_ke 8y ago
I'd argue that python needs an async django, which will hopefully be django in a few releases.
- scardine 8y ago
  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/ https://sanic.readthedocs.io/en/latest/
  - m_ke 8y ago
    We actually use Sanic alongside Django for some of our machine learning services. Has been working well so far.
  - amorphic 8y ago
    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...)?
    - abuckenheimer 8y ago
      [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 https://aiohttp.readthedocs.io/en/stable/faq.html#id1
    - scardine 8y ago
      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.
- diminoten 8y ago
  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 winners in the space yet (compare uvicorn's quickstart example to this project's before you throw that project out as an example). This is Truly New Shit, and I'm pumped these two devs are working on it together.
  - m_ke 8y ago
    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/ https://www.aeracode.org/2018/06/04/django-async-roadmap/ From what I understand ASGI was developed by Andrew Godwin for Django Channels.
    - diminoten 8y ago
      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.
    - amorphic 8y ago
      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 https://www.youtube.com/watch?v=-7taKQnndfo
  - tomchristie 8y ago
    Yo. Yeah my (bit of) involvement is mostly around wanting to help guide the new ASGI ecosystem. For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently. Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework. That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/ https://www.starlette.io/ (FWIW Starlette also composes all those bits and pieces into a framework in its own right)
- jklehm 8y ago
  If you can manage with Flask there's Quart [1] [1] https://gitlab.com/pgjones/quart https://gitlab.com/pgjones/quart
  - bpicolo 8y ago
    I've been using quart for some projects recently. Was super easy to move to from flask (though had to upstream a couple compat fixes). Overall, super pleased
- yla92 8y ago
  Tornado[0] is not on per when it comes to features richness of Django. Yet, it's async and a joy to write. You should check it out if you have not. I would like to hear more from others about Tornado vs other Python frameworks as well. [0]: http://www.tornadoweb.org/en/stable/ http://www.tornadoweb.org/en/stable/
  - amorphic 8y ago
    +1 I used Tornado in the past because it had an async event loop before it was native to Python. So much simpler than having to set up wsgi servers etc with the added benefit of easily-configured background tasks (like having cron jobs built in to your application). This is really good when you're building an application that you want other people to be able to install and run easily. It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.
- crgwbr 8y ago
  Django’s channels project actually gets pretty close to this. It’s not flawless, but it makes it fairly simple to support websockets, etc.
- biggio 8y ago
  There are numerous async frameworks already, aiohttp to name one, in addition to others mentioned above.
  - m_ke 8y ago
    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.
basil-rash 8y ago
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 typing increases productivity in these "short scripts". For instance, the second I decide to refactor, I know that even once I think I've cleaned everything up, the next few minutes will be spent running the code a few times to flush out all the type errors. Python is not my primary language, so that could play a part in the issues I have, but if I am allowed to lose humility for a second or two: even though I primarily use TS, my Python is still, in my opinion, stronger than many of my (college student) peers. I hate to imagine all the issues a novice would face. To be fair, I haven't used mypy in a while. I remember that being decent, but nowhere near the level of TS, in terms of both the power of the type system and the editor support.
- basil-rash 8y ago
  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.
  - jnwatson 8y ago
    You need `import typing`, and an editor with integrated mypy (e.g. vim). It is almost as good as static typing.
    - basil-rash 8y ago
      Initial thoughts from looking through https://docs.python.org/3/library/typing.html# 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)
giancarlostoro 8y ago
I love Python for back-end web development, it's hard to shake it off of me, except if I were doing ASP .NET Core (I'm ok with C#). So I think in that area it's pretty solid, but I agree, I wish the GUI side of Python got more love, maybe a proper RAD environment like VB had, hate on VB all you want, but damn it was neat. I'm surprised Kivy doesn't have a RAD editor, if it does then I am way behind. For now I'll keep using Tkinter.

m_ke 8y ago

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

scardine 8y ago
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/ https://sanic.readthedocs.io/en/latest/
- m_ke 8y ago
  We actually use Sanic alongside Django for some of our machine learning services. Has been working well so far.
- amorphic 8y ago
  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...)?
  - abuckenheimer 8y ago
    [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 https://aiohttp.readthedocs.io/en/stable/faq.html#id1
  - scardine 8y ago
    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.
diminoten 8y ago
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 winners in the space yet (compare uvicorn's quickstart example to this project's before you throw that project out as an example). This is Truly New Shit, and I'm pumped these two devs are working on it together.
- m_ke 8y ago
  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/ https://www.aeracode.org/2018/06/04/django-async-roadmap/ From what I understand ASGI was developed by Andrew Godwin for Django Channels.
  - diminoten 8y ago
    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.
  - amorphic 8y ago
    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 https://www.youtube.com/watch?v=-7taKQnndfo
- tomchristie 8y ago
  Yo. Yeah my (bit of) involvement is mostly around wanting to help guide the new ASGI ecosystem. For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently. Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework. That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/ https://www.starlette.io/ (FWIW Starlette also composes all those bits and pieces into a framework in its own right)
jklehm 8y ago
If you can manage with Flask there's Quart [1] [1] https://gitlab.com/pgjones/quart https://gitlab.com/pgjones/quart
- bpicolo 8y ago
  I've been using quart for some projects recently. Was super easy to move to from flask (though had to upstream a couple compat fixes). Overall, super pleased
yla92 8y ago
Tornado[0] is not on per when it comes to features richness of Django. Yet, it's async and a joy to write. You should check it out if you have not. I would like to hear more from others about Tornado vs other Python frameworks as well. [0]: http://www.tornadoweb.org/en/stable/ http://www.tornadoweb.org/en/stable/
- amorphic 8y ago
  +1 I used Tornado in the past because it had an async event loop before it was native to Python. So much simpler than having to set up wsgi servers etc with the added benefit of easily-configured background tasks (like having cron jobs built in to your application). This is really good when you're building an application that you want other people to be able to install and run easily. It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.
crgwbr 8y ago
Django’s channels project actually gets pretty close to this. It’s not flawless, but it makes it fairly simple to support websockets, etc.
biggio 8y ago
There are numerous async frameworks already, aiohttp to name one, in addition to others mentioned above.
- m_ke 8y ago
  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.

basil-rash 8y ago

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 typing increases productivity in these "short scripts". For instance, the second I decide to refactor, I know that even once I think I've cleaned everything up, the next few minutes will be spent running the code a few times to flush out all the type errors. Python is not my primary language, so that could play a part in the issues I have, but if I am allowed to lose humility for a second or two: even though I primarily use TS, my Python is still, in my opinion, stronger than many of my (college student) peers. I hate to imagine all the issues a novice would face. To be fair, I haven't used mypy in a while. I remember that being decent, but nowhere near the level of TS, in terms of both the power of the type system and the editor support.

basil-rash 8y ago
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.
- jnwatson 8y ago
  You need `import typing`, and an editor with integrated mypy (e.g. vim). It is almost as good as static typing.
  - basil-rash 8y ago
    Initial thoughts from looking through https://docs.python.org/3/library/typing.html# 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)

giancarlostoro 8y ago

I love Python for back-end web development, it's hard to shake it off of me, except if I were doing ASP .NET Core (I'm ok with C#). So I think in that area it's pretty solid, but I agree, I wish the GUI side of Python got more love, maybe a proper RAD environment like VB had, hate on VB all you want, but damn it was neat. I'm surprised Kivy doesn't have a RAD editor, if it does then I am way behind. For now I'll keep using Tkinter.