Live data from Hacker News

Python web micro-framework battle

slideshare.net

51–59 of 59 posts

Re: Python web micro-framework battle

#51

Earlier quoted context omitted.

Seems pretty defensive to me. How does, say, separating out the route and the view declarations help your application? Code like this: config = Configurator() config.add_route('hello', '/hello/{name}') config.add_view(hello_world, route_name='hello') is really just boilerplate, which is better done as a decorator. Count how many times the word 'hello' appears in that snippet above. And this is just for a hello world…

The ordering of your patterns matters, so that is done at config time. However it's very common to want to have unrelated code executed depending on the type of request to a URL. Pyramid will do this lookup for you, rather than polluting a gigantic view function with multiple code-paths for distinct functionality. @view_config(route_name='hello', request_method='GET') def get_hello(request): return Response('a GET re…

Bottle and Flask actually allow for this too. Bottle's variant:

   @route('/hello/:name', method='GET')
   def hello_get(name):
       return 'Hello %s' % name

   @route('/hello/:name', method='POST')
   def hello_post(name):
       return 'Hello %s' % name
Pyramid permits a larger variety of predicates (including custom ones), however: https://docs.pylonsproject.org/projects/pyramid/1.2/narr/vie...

Re: Python web micro-framework battle

#52
post #51

Earlier quoted context omitted.

The ordering of your patterns matters, so that is done at config time. However it's very common to want to have unrelated code executed depending on the type of request to a URL. Pyramid will do this lookup for you, rather than polluting a gigantic view function with multiple code-paths for distinct functionality. @view_config(route_name='hello', request_method='GET') def get_hello(request): return Response('a GET re…

Bottle and Flask actually allow for this too. Bottle's variant: @route('/hello/:name', method='GET') def hello_get(name): return 'Hello %s' % name @route('/hello/:name', method='POST') def hello_post(name): return 'Hello %s' % name Pyramid permits a larger variety of predicates (including custom ones), however: https://docs.pylonsproject.org/projects/pyramid/1.2/narr/vie...

Yes but while implicit route ordering works a lot of the time, I'll gladly keep Pyramid's concept of explicit ordering, which is the main source of verbosity in the Pyramid setup which separates routes from views.

Re: Python web micro-framework battle

#53
post #51

Earlier quoted context omitted.

Bottle and Flask actually allow for this too. Bottle's variant: @route('/hello/:name', method='GET') def hello_get(name): return 'Hello %s' % name @route('/hello/:name', method='POST') def hello_post(name): return 'Hello %s' % name Pyramid permits a larger variety of predicates (including custom ones), however: https://docs.pylonsproject.org/projects/pyramid/1.2/narr/vie...

Yes but while implicit route ordering works a lot of the time, I'll gladly keep Pyramid's concept of explicit ordering, which is the main source of verbosity in the Pyramid setup which separates routes from views.

The order the decorators are run at import time is explicit. Everybody loves module-scope programming and import-time side-effects! What's wrong with you man? ;-)

Re: Python web micro-framework battle

#54
post #38

This seems like an illogical conclusion. I didn't see API Design mentioned once in any of these slides. Aside from Python3 Support (which is a bit irrelevant at this point), what does Bottle actually offer that Flask does not? Nothing, that I can see. Flask has a thriving community, first-class extensions, extremely high quality documentation, and an elegant API. It even lets you dip down into the lower-level werkzeu…

You have to consider his primary use case (which he explains in the video). He's not writing web apps per se, but wrapping up existing python code in a simple http frontend. From that point of view I agree with him that bottle is quicker and easier to use than flask. That being said, flask is easily my go to framework for getting serious web app work done in python.

I did just this for a presentation:

https://bitbucket.org/mdg/cohpy-hips-presentation/src/89b3d2...

Re: Python web micro-framework battle

#55
post #34
post #31

Earlier quoted context omitted.

Flask also has more features and unless you find a way to accurately rate features for their usefulness and compare all those somehow the LOC metric has practically no meaning. It would be much more interesting for potential users if people started comparing lines of documentation(LOD) and showed the quotient lines of tests/lines of code.

LOC and LOD suffer from the same problem: You can write (or generate) lots of code or documentation that does not help the user. You can even write docs that confuse the user, repeat a lot, to not get to the point and so on. In that case, more is even worse than less. There is no number to measure the usefulness of a framework or the quality of code. And there is no point in comparing frameworks just by numbers.

You will notice bad documentation almost immediately which makes the disadvantage of using LOD as a metric practically irrelevant.

Re: Python web micro-framework battle

#56
post #37
post #32

Earlier quoted context omitted.

You can write Flask applications without ever having heard of the term blueprint. I don't see how they could complicate things.

If you are planning to have a lot of functionality, i.e. routings, you need some way to modularise. Bottle does seem to have a more pythonic way. Flask creates new concepts that seem counter intuitive to me at the first look.

Bottle has no concept at all for this, besides sticking independent applications together.

You can do that with Flask as well, in fact the documentation there is an entire document describing various approaches[1].

Blueprints are a "new" concept but the approach is basically the same, however they are able to interact with the application at a Flask-level, they can modify the application and share information like the configuration.

This is something Bottle doesn't support at a framework level, forcing you to abuse the functionality it provides from a semantical standpoint.

This concept is more difficult to understand but than again it is very trivial compared to other concepts any web developer should grasp.

[1]: http://flask.pocoo.org/docs/patterns/appdispatch/

Re: Python web micro-framework battle

#57
post #42

Earlier quoted context omitted.

Bottle's API easy to understand and has sane defaults. It also doesn't require any boiler-plate code and isn't saddled with any dependency baggage. I found it trivial to wire in the Rocket web server as a replacement for WSGIref which had the added advantage I could wrap the startup in a small hunk of code I found over on the ActiveState forum to turn my app into a Windows service. Which, after half a day of beating…

Comments with critical, dogmatic hyperboles in them like this drive me nuts in general. Here are the hyperboles in this comment with the translations to normal English. - "saddled with any dependency baggage" == "has no dependencies" - "beating on Flask" == "using Flask" - "shrug" == "i didn't spend a lot of time on this" - "Flask was completely unsuitable for that" == "I was unwilling to ask for help from the people…

You're right, I indulged in too much purple prose there. Sorry.

Would you expand on what you meant by:

> The context of the comment makes it seem like it's subpar on these things.

What I intended to get across was that Bottle, being a single file at ~2700 lines, makes it convenient to scan the code to see exactly what it is doing (or not). It also doesn't require a lot of typing to wire a function to a URL and offers some nice syntactic sugar while doing so: you don't have to @route things you can @get them or @post them (it's probably my Java background that makes me think in terms of separate code paths for the different HTTP verbs).

My take on a more detailed (and hopefully hyperbole-free) summation of my original post is:

"Because this was a short timeframe prototype, they had no Linux VM available in the lab so I had to use Windows. I found a recipe that let me run Python stuff as a service which I was able to wrap around Bottle more quickly than I was able to with the other frameworks I tried. Because I was working on a machine that had no access out to the internet, I had no virtualenv and had to instead bundle all my stuff up by hand."

Re: Python web micro-framework battle

#58

Earlier quoted context omitted.

Bottle's API easy to understand and has sane defaults. It also doesn't require any boiler-plate code and isn't saddled with any dependency baggage. I found it trivial to wire in the Rocket web server as a replacement for WSGIref which had the added advantage I could wrap the startup in a small hunk of code I found over on the ActiveState forum to turn my app into a Windows service. Which, after half a day of beating…

Fear of packages is a terrible thing. But, I see what you're saying. FWIW, there's a Flask-kitchensink project that lets you run it out of a single file, if you're so inclined.

Thanks for the pointer to that project. Hopefully I won't have to do another of these off-the-cuff throwaways again (which means I won't have to leave the comfort-zone of virtualenv on Linux), but if I do, I now know where to find the kitchen sink. =)

Re: Python web micro-framework battle

#59
post #42

Earlier quoted context omitted.

Comments with critical, dogmatic hyperboles in them like this drive me nuts in general. Here are the hyperboles in this comment with the translations to normal English. - "saddled with any dependency baggage" == "has no dependencies" - "beating on Flask" == "using Flask" - "shrug" == "i didn't spend a lot of time on this" - "Flask was completely unsuitable for that" == "I was unwilling to ask for help from the people…

You're right, I indulged in too much purple prose there. Sorry. Would you expand on what you meant by: > The context of the comment makes it seem like it's subpar on these things. What I intended to get across was that Bottle, being a single file at ~2700 lines, makes it convenient to scan the code to see exactly what it is doing (or not). It also doesn't require a lot of typing to wire a function to a URL and offers…

Wow, great way to take criticism! Thank you.
Post reply on HN