God, this is ridiculous. I can't advance slides, when I do, it skips multiple slides at a time and I have to register to download a copy that I might actually be able to view.
Python web micro-framework battle
41–50 of 59 posts
Re: Python web micro-framework battle
#42This 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…
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 who use Flask"
Additionally, Flask is also "easy to understand" and has "sane defaults", and it doesn't "require any boilerplate code" either. The context of the comment makes it seem like it's subpar on these things.
I'm all for people pointing out fitness of purpose for various frameworks, but this comment might have been better phrased as "I use Windows. I happened to find a recipe that let me run Bottle as a Windows service. That made it easier for me to use Bottle. Also, I like being able to deploy without the use of packaging tools."
Re: Python web micro-framework battle
#43Earlier 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.
> Flask creates new concepts that seem counter intuitive to me at the first look.
You don't have to use them. Just do the Bottle way if you prefer.
Re: Python web micro-framework battle
#44God, this is ridiculous. I can't advance slides, when I do, it skips multiple slides at a time and I have to register to download a copy that I might actually be able to view.
[deleted]
Re: Python web micro-framework battle
#45Line count is a silly way to score when all are around the same anyway (fewer than 100 lines). And the framework line count is another metric that shouldn't matter. That said, really the only valid point here against Flask is Python 3 support. Other than that Bottle and Flask are pretty much on par with each other.
The point behind the line count is that simpler code on the framework side counts, particularly when the documentation is sketchy or unclear. Less code for the same functionality means that you have less reading to do when learning the framework's intricacies.
Re: Python web micro-framework battle
#46Discounting 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.
Compare it with Bottle's version though and it doesn't look quite so concise any more: http://bottlepy.org/docs/dev/
Re: Python web micro-framework battle
#47Discounting 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.
Compare it with Bottle's version though and it doesn't look quite so concise any more: http://bottlepy.org/docs/dev/
Seems appropriate to link this here: https://docs.pylonsproject.org/projects/pyramid/1.2/designde...
Re: Python web micro-framework battle
#48Earlier quoted context omitted.
Compare it with Bottle's version though and it doesn't look quite so concise any more: http://bottlepy.org/docs/dev/
Seems appropriate to link this here: https://docs.pylonsproject.org/projects/pyramid/1.2/designde...
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')
Re: Python web micro-framework battle
#49Earlier quoted context omitted.
Seems appropriate to link this here: https://docs.pylonsproject.org/projects/pyramid/1.2/designde...
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…
In a more traditional Pyramid app it would be done more like:
from pyramid.view import view_config
from pyramid.response import Response
from paste.httpserver import serve
@view_config(route_name='hello')
def hello_world(request):
return Response('Hello %(person)s' % request.matchdict)
if __name__ == '__main__':
config = Configurator()
config.add_route('hello', '/hello/{person}')
config.scan()
serve(config.make_wsgi_app())
The rationale for putting the route ordering in imperative code instead of using decorator declaration order is in the document I linked. I'm not particularly interested in crippling Pyramid for larger apps to race to the bottom of the LOC count. It's succinct enough and works for truly large apps too.
Re: Python web micro-framework battle
#50Earlier quoted context omitted.
Seems appropriate to link this here: https://docs.pylonsproject.org/projects/pyramid/1.2/designde...
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 request for %s' % request.matchdict['name'])
@view_config(route_name='hello', request_method='POST')
def post_hello(request):
return Response('stored info')
config = Configurator()
config.add_route('hello', '/hello/{name}')
config.scan()
app = config.make_wsgi_app()