Live data from Hacker News

Python web micro-framework battle

slideshare.net

31–40 of 59 posts

Re: Python web micro-framework battle

#31
post #26

Earlier quoted context omitted.

Those are not lines of code. That includes docstrings which all of Pocoo code is full of. If you want to measure lines of code you at least have to skip comments, docstrings and empty lines. And for that there is sloccount. This also includes the testsuites btw. With this little script ( http://paste.pocoo.org/show/465885/ ) I get the following results: Flask 1467 LOC Jinja2 6560 LOC Werkzeug 9923 LOC Bottle 1910 LOC…

There are better ways to count LOC, I agree. But the idea is the same: Bottle does what it does with 1/10 of the code that runs flask.

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.

Re: Python web micro-framework battle

#32
post #30

I also like the way bottle handles static files and apps compared to flask. I lost flask when it went into blueprints. Bottle seems more intuitive, though there is not much difference.

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

Re: Python web micro-framework battle

#33
post #7

Discounting pyramid as a microframework doesn't seem valid, given that it can be scaled up or down arbitrarily. https://docs.pylonsproject.org/projects/pyramid/1.2/ has an extremely concise pyramid web app above the fold.

Indeed. The whole concept of when a framework starts or stops being micro is quite arbitrary.

Re: Python web micro-framework battle

#34
post #31
post #26

Earlier quoted context omitted.

There are better ways to count LOC, I agree. But the idea is the same: Bottle does what it does with 1/10 of the code that runs flask.

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.

Re: Python web micro-framework battle

#35

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…

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 on Flask, I wasn't able to figure out.

shrug

For me, it's all about fitness for purpose. In the end, the prototype consisted of four files (Bottle, Rocket, the Service wrapper and my code) with no other dependencies. Made it a lot easier for the overworked Windows admins to deploy. Flask was completely unsuitable for that.

Re: Python web micro-framework battle

#37
post #32
post #30

I also like the way bottle handles static files and apps compared to flask. I lost flask when it went into blueprints. Bottle seems more intuitive, though there is not much difference.

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.

Re: Python web micro-framework battle

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

Re: Python web micro-framework battle

#39
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.

Great point. Interesting.

Re: Python web micro-framework battle

#40

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…

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.

Post reply on HN