12 ms·

Show HN: Ice – WSGI microframework to develop small web applications in Python

53 points by icepy 9y ago

_ix 9y ago
This looks like a whole lot of work for a 0.0.1 release so I must ask... why might I choose Ice over Flask?
- guitarbill 9y ago
  Or Bottle, CherryPy, and others? I'm sure there's room for another framework, but it would be good to elaborate what Ice's raison d'être is, and what it's strengths and weaknesses are.
  - foo101 9y ago
    Following text quoted from the README[1]: "This microframework was born as a result of experimenting with WSGI framework. Since what started as a small experiment turned out to be several hundred lines of code, it made sense to share the source code on the web, just in case anyone else benefits from it. This microframework has a very limited set of features currently. It may be used to develop small web applications. For large web applications, it may make more sense to use a more wholesome framework such as Flask or Django. It is possible that you may find that this framework is missing a useful API that another major framework provides. In such a case, you have direct access to the WSGI internals to do what you want via the documented API. If you believe that a missing feature or a bug fix would be useful to others, you may report an issue, or even better, fork this project on GitHub, develop the missing feature or the bug fix, and send a patch or a pull request. In fact, you are very welcome to do so, and turn this experimental project into a matured one by contributing your code and expertise." [1]: https://github.com/susam/ice#why-ice https://github.com/susam/ice#why-ice
  - eeZah7Ux 9y ago
    Bottle is faster and simpler.
    - samoright 9y ago
      What is Bottle faster and simpler than? CherryPy? Flask? Ice? Do you have benchmarking results to support your claim? What aspects of Bottle are simpler? Writing code using it? Deploying it? Can you elaborate with some concrete examples?
- sametmax 9y ago
  Even more: why WSGI ? We need a django of the async world. We need something in Python to compete with nodejs, or even meteor, with async/await as primary tool. And maybe a aWSGI support. But WSGI ? We have everything we need. They are proven tools. They work. Have great ecosystems and documentations. They do the job perfectly for non real time oriented web site. We don't need another one.
  - mephitix 9y ago
    Seen Sanic[1] yet? I've become a fan... works well with asyncpg[2] too. [1]: https://github.com/channelcat/sanic https://github.com/channelcat/sanic [2]: https://github.com/MagicStack/asyncpg https://github.com/MagicStack/asyncpg
    - sametmax 9y ago
      It's very limited. We are far, far away from what django or meteor can provide. The API, while using async, is kinda old school (no plugins, namespaces, conf hooks...) and low level for some stuff (where is my task queue ?), and yet too high level for others (you give up control of the even loop policy completely). It's a nice attempt, but it's barely a draft IMO.
      - eric_bullington 9y ago
        When did you last use sanic? It's far from limited, and advancing quickly. However, it's a microframework, so it's true that you'll not get a full Django-like experience (and Meteor isn't even in the same class of web framework as Django or microframeworks like Sanic, so there's nothing to compare there either). But with respect to microframeworks, Sanic is getting pretty close to feature parity with Flask, only asynchronously. I'm not sure what kind of plugin architecture you're looking for, but you can do middleware with Sanic. Also custom protocols. Also decorators (e.g., for auth). And for namespacing, there are blueprints. I'm not sure what you mean by "conf hooks". It does help with Sanic if you're already familiar with Flask. Sanic is very close to an async version of Flask. For a task queue, you can run async tasks with Sanic alone using `app.add_task(some_async_function)`. It's also simple to use apscheduler if you want a more full-feature async scheduler. Example: from apscheduler.schedulers.asyncio import AsyncIOScheduler from sanic import Sanic app = Sanic() async def tick(): print('Work!') @app.listener('before_server_start') async def initialize_scheduler(app, loop): scheduler = AsyncIOScheduler({'event_loop': loop}) scheduler.add_job(tick, 'interval', seconds=1) scheduler.start() if __name__ == "__main__": app.run(host="0.0.0.0", port=8000, debug=True) Finally, unless things have changed, you should be able to set event loop policy with `asyncio.set_event_loop_policy`, have you tried it?
Animats 9y ago
The minimal implementation for the application side in Python is "flipflop". It calls your function, and you return a HTML string as a result. That's enough to hook up a Python program as a web server. Anything beyond that, such as input data parsing or generating HTML from a template or tree, should be a library, not a "framework". You might want multiple libraries from different sources.
- knrz 9y ago
  Reading this reminds me of the Clojure style of code... anyone else?
  - afghanPower 9y ago
    Yeah, my first thought as well. The Rich Hickey spirit is leaking..
- sametmax 9y ago
  It seems the entire Python community disagree, and made the monolithic Django the most popular framework. No the minimalist flask. Not the very composable pyramid. Django. And the reasons for that are: - choosing tools takes time and resources. - integrating them takes time and resources. - keep up to update the stack so it works well together takes time and resources. - multiple tools mean multiple docs. - you need to train your newcomers to your whole whole stack. - when you change project, you have to learn a new stack. - multiple tools won't be nearly as well integrated or full featured than the big framework. Have you tried flask-admin ? It's very far away from django-admin. - ecosystems build on common grounds. They assume they have tools, configurations, conventions. If you just use anything and everything, no third party tool car easily fit in your stack. E.G: django has a lot of nice libs around authentication because 3rd parties can rely on having a central User model. It's terribly unperfect, but it's really productive. - JS has this philosophy, and it's a terrible horrible no good messy pain.
  - deleted 9y ago
    [deleted]
legostormtroopr 9y ago
Why invent a new string matching format, instead of just using regular expressions?
- sametmax 9y ago
  They allow regular expression. But having use Django's regex matching a lot, and the one provided with werkzeug, I can tell you the second one is much more productive: 99% of the case you don't need a complex pattern and you are very happy to be able to just say "hey gime 'stuff' here" instead of crafting things like "(?P<stuff>\d+)" . For the rare use case, you just fall back on regexes.
- icepy 9y ago
  You can just use regular expressions if you prefer that. * https://icepy.readthedocs.io/en/latest/tutorial.html#regular-expression-routes https://icepy.readthedocs.io/en/latest/tutorial.html#regular... * https://icepy.readthedocs.io/en/latest/tutorial.html#interpretation-of-request-path-pattern https://icepy.readthedocs.io/en/latest/tutorial.html#interpr... * https://github.com/susam/ice/blob/master/test/test_router.py#L177 https://github.com/susam/ice/blob/master/test/test_router.py...
deleted 9y ago
[deleted]

53 points by icepy 9y ago

_ix 9y ago

This looks like a whole lot of work for a 0.0.1 release so I must ask... why might I choose Ice over Flask?

guitarbill 9y ago
Or Bottle, CherryPy, and others? I'm sure there's room for another framework, but it would be good to elaborate what Ice's raison d'être is, and what it's strengths and weaknesses are.
- foo101 9y ago
  Following text quoted from the README[1]: "This microframework was born as a result of experimenting with WSGI framework. Since what started as a small experiment turned out to be several hundred lines of code, it made sense to share the source code on the web, just in case anyone else benefits from it. This microframework has a very limited set of features currently. It may be used to develop small web applications. For large web applications, it may make more sense to use a more wholesome framework such as Flask or Django. It is possible that you may find that this framework is missing a useful API that another major framework provides. In such a case, you have direct access to the WSGI internals to do what you want via the documented API. If you believe that a missing feature or a bug fix would be useful to others, you may report an issue, or even better, fork this project on GitHub, develop the missing feature or the bug fix, and send a patch or a pull request. In fact, you are very welcome to do so, and turn this experimental project into a matured one by contributing your code and expertise." [1]: https://github.com/susam/ice#why-ice https://github.com/susam/ice#why-ice
- eeZah7Ux 9y ago
  Bottle is faster and simpler.
  - samoright 9y ago
    What is Bottle faster and simpler than? CherryPy? Flask? Ice? Do you have benchmarking results to support your claim? What aspects of Bottle are simpler? Writing code using it? Deploying it? Can you elaborate with some concrete examples?
sametmax 9y ago
Even more: why WSGI ? We need a django of the async world. We need something in Python to compete with nodejs, or even meteor, with async/await as primary tool. And maybe a aWSGI support. But WSGI ? We have everything we need. They are proven tools. They work. Have great ecosystems and documentations. They do the job perfectly for non real time oriented web site. We don't need another one.
- mephitix 9y ago
  Seen Sanic[1] yet? I've become a fan... works well with asyncpg[2] too. [1]: https://github.com/channelcat/sanic https://github.com/channelcat/sanic [2]: https://github.com/MagicStack/asyncpg https://github.com/MagicStack/asyncpg
  - sametmax 9y ago
    It's very limited. We are far, far away from what django or meteor can provide. The API, while using async, is kinda old school (no plugins, namespaces, conf hooks...) and low level for some stuff (where is my task queue ?), and yet too high level for others (you give up control of the even loop policy completely). It's a nice attempt, but it's barely a draft IMO.
    - eric_bullington 9y ago
      When did you last use sanic? It's far from limited, and advancing quickly. However, it's a microframework, so it's true that you'll not get a full Django-like experience (and Meteor isn't even in the same class of web framework as Django or microframeworks like Sanic, so there's nothing to compare there either). But with respect to microframeworks, Sanic is getting pretty close to feature parity with Flask, only asynchronously. I'm not sure what kind of plugin architecture you're looking for, but you can do middleware with Sanic. Also custom protocols. Also decorators (e.g., for auth). And for namespacing, there are blueprints. I'm not sure what you mean by "conf hooks". It does help with Sanic if you're already familiar with Flask. Sanic is very close to an async version of Flask. For a task queue, you can run async tasks with Sanic alone using `app.add_task(some_async_function)`. It's also simple to use apscheduler if you want a more full-feature async scheduler. Example: from apscheduler.schedulers.asyncio import AsyncIOScheduler from sanic import Sanic app = Sanic() async def tick(): print('Work!') @app.listener('before_server_start') async def initialize_scheduler(app, loop): scheduler = AsyncIOScheduler({'event_loop': loop}) scheduler.add_job(tick, 'interval', seconds=1) scheduler.start() if __name__ == "__main__": app.run(host="0.0.0.0", port=8000, debug=True) Finally, unless things have changed, you should be able to set event loop policy with `asyncio.set_event_loop_policy`, have you tried it?

Animats 9y ago

The minimal implementation for the application side in Python is "flipflop". It calls your function, and you return a HTML string as a result. That's enough to hook up a Python program as a web server. Anything beyond that, such as input data parsing or generating HTML from a template or tree, should be a library, not a "framework". You might want multiple libraries from different sources.

knrz 9y ago
Reading this reminds me of the Clojure style of code... anyone else?
- afghanPower 9y ago
  Yeah, my first thought as well. The Rich Hickey spirit is leaking..
sametmax 9y ago
It seems the entire Python community disagree, and made the monolithic Django the most popular framework. No the minimalist flask. Not the very composable pyramid. Django. And the reasons for that are: - choosing tools takes time and resources. - integrating them takes time and resources. - keep up to update the stack so it works well together takes time and resources. - multiple tools mean multiple docs. - you need to train your newcomers to your whole whole stack. - when you change project, you have to learn a new stack. - multiple tools won't be nearly as well integrated or full featured than the big framework. Have you tried flask-admin ? It's very far away from django-admin. - ecosystems build on common grounds. They assume they have tools, configurations, conventions. If you just use anything and everything, no third party tool car easily fit in your stack. E.G: django has a lot of nice libs around authentication because 3rd parties can rely on having a central User model. It's terribly unperfect, but it's really productive. - JS has this philosophy, and it's a terrible horrible no good messy pain.
- deleted 9y ago
  [deleted]

legostormtroopr 9y ago

Why invent a new string matching format, instead of just using regular expressions?

sametmax 9y ago
They allow regular expression. But having use Django's regex matching a lot, and the one provided with werkzeug, I can tell you the second one is much more productive: 99% of the case you don't need a complex pattern and you are very happy to be able to just say "hey gime 'stuff' here" instead of crafting things like "(?P<stuff>\d+)" . For the rare use case, you just fall back on regexes.
icepy 9y ago
You can just use regular expressions if you prefer that. * https://icepy.readthedocs.io/en/latest/tutorial.html#regular-expression-routes https://icepy.readthedocs.io/en/latest/tutorial.html#regular... * https://icepy.readthedocs.io/en/latest/tutorial.html#interpretation-of-request-path-pattern https://icepy.readthedocs.io/en/latest/tutorial.html#interpr... * https://github.com/susam/ice/blob/master/test/test_router.py#L177 https://github.com/susam/ice/blob/master/test/test_router.py...

deleted 9y ago

[deleted]