Pyramid Framework


Published on

The good, the bad and why it's great

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Pyramid Framework

  1. 1. Pyramid Framework The good, the bad and why it's great. Anatoly Bubenkov @bubenkoff Paylogic Groningen Office 2.09.2013
  2. 2. What is pyramid? ● Pyramid is a general, open source, Python web application development framework. ● The first release of Pyramid (repoze.bfg) in July of 2008. ● At the end of 2010, repoze.bfg ->Pyramid. ● And joined Pylons project. Pyramid was inspired by Zope, Pylons (version 1.0) and Django. So Pyramid gets best from several concepts, combining them into a unique web framework.
  3. 3. Zope roots :) ● Many features of Pyramid trace their origins back to Zope. ● Like Zope applications, Pyramid applications can be easily extended ● The concepts of traversal and declarative security in Pyramid were pioneered first in Zope.
  4. 4. What Makes Pyramid Unique Good equally for small and big applications. Common case: ● You start from small app using some framework, everything is ok ● App grows, you add features, and framework is now not able to satisfy your needs ● You end up rewriting app/parts of it using different framework ● Pyramid ‘is’ for both big and small apps. Architected to build complex things from simple, which always work.
  5. 5. I want minimal! One-file app: from wsgiref.simple_server import make_server from pyramid.config import Configurator from pyramid.response import Response def hello_world(request): return Response('Hello %(name)s!' % request.matchdict) if __name__ == '__main__': config = Configurator() config.add_route('hello', '/hello/{name}') config.add_view(hello_world, route_name='hello') app = config.make_wsgi_app() server = make_server('', 8080, app) server.serve_forever()
  6. 6. Decorator-based views Possible, but not required, that you configure view as decorator for the view function: from pyramid.view import view_config from pyramid.response import Response @view_config(route_name='fred') def fred_view(request): return Response('fred') The huge difference with ‘other’ frameworks: decorator actually does NOT change the view function directly. This process is separated to a stage named configuration scan, allowing the override and customization of existing apps.
  7. 7. Class-based and function-based views Here’s a view callable defined as a function: from pyramid.response import Response from pyramid.view import view_config @view_config(route_name='aview') def aview(request): return Response('one') Here’s a few views defined as methods of a class instead: from pyramid.response import Response from pyramid.view import view_config class AView(object): def __init__(self, request): self.request = request @view_config(route_name='view_one') def view_one(self): return Response('one') @view_config(route_name='view_two') def view_two(self): return Response('two')
  8. 8. Assets? Templates are also assets! ● Asset specifications are strings that contain both a Python package name and a file or directory name, e.g. MyPackage: static/index.html. ● An asset specification can refer to a template, a translation directory, or any other package-bound static resource. ● Because asset specifications are used heavily in Pyramid, they provided a way to allow users to override assets easily and in granular way.
  9. 9. Templating: pluggable ● Pyramid has a structured API that allows for pluggability of “renderers”. ● Templating systems such as Mako, Genshi, Chameleon, and Jinja2 can be treated as renderers. ● Renderer bindings for all of these templating systems already exist for use in Pyramid. ● But if you’d rather use another, it’s not a big deal.
  10. 10. Views should be declared as views Why the view function should return the rendered stuff? It’s hard to cover it with tests. Much better to separate logic. For example, instead of: from pyramid.renderers import render_to_response def myview(request): return render_to_response('myapp:templates/', {'a':1}, request=request) You CAN do this: from pyramid.view import view_config @view_config(renderer='myapp:templates/') def myview(request): return {'a':1}
  11. 11. Event system Pyramid provides (and uses itself internally) the powerful event system. It emits events during its request processing lifecycle. You can subscribe any number of listeners to these events. For example, to be notified of a new request, you can subscribe to the NewRequest event. To be notified that a template is about to be rendered, you can subscribe to the BeforeRender event, and so forth.
  12. 12. Using event system Imperative from import NewRequest from subscribers import mysubscriber # "config" below is assumed to be an instance of a # pyramid.config.Configurator object config.add_subscriber(mysubscriber, NewRequest) Decorator from import NewRequest from import subscriber @subscriber(NewRequest) def mysubscriber(event): = 1 The big difference here, is that events are used even in the core, request processing, so you can easily modify it during it’s life cycle!
  13. 13. What about speed? Answer: fast enough ● Apache 2.2.14 was used. Just because it’s standard ● Python 2.6.5 and mod_wsgi 2.8 (embedded mode) were used.
  14. 14. No singletons ● Import of a Pyramid application needn’t have any “import-time side effects”. ● Now try to import and and work with django app without ‘settings’ :) ● Helps a lot deploying your system using an asynchronous server. ● You can even run multiple copies of a similar but not identically configured Pyramid application within the same Python process.
  15. 15. View predicates and many views per route ● Pyramid allows you to associate more than one view per route. ● You can create a route with the pattern /items and when the route is matched, you can shuffle off the request to one view if the request method is GET, another view if the request method is POST ● A system known as “view predicates” allows for this. ● Predicates: request_type, request_method, request_param, match_param, and lot more, and CUSTOM ones Simple example: config.add_view('my.package.GET_view', route_name='xhr_route', xhr=True, permission='view', request_method='GET')
  16. 16. Transaction management ● stolen from Zope ● it’s potentially bad to have explicit commits because you can accidentally change model after commit ● no explicit commit (but it’s of course still up to you) ● allows you to synchronize commits between multiple databases, and allows you to do things like conditionally send email if a transaction commits, but otherwise keep quiet.
  17. 17. Configuration: conflict detection and custom directives ● Pyramid’s configuration system keeps track of your configuration statements ● Identical, or ‘conflicting’ statements are complained ● You can have your custom constraints for configuration directives from pyramid.config import Configurator def add_protected_xhr_views(config, module): module = config.maybe_dotted(module) for method in ('GET', 'POST', 'HEAD'): view = getattr(module, 'xhr_%s_view' % method, None) if view is not None: config.add_view(view, route_name='xhr_route', xhr=True, permission='view', request_method=method) config = Configurator() config.add_directive('add_protected_xhr_views', add_protected_xhr_views)
  18. 18. Configuration: conflict detection and custom directives Then instead of: from pyramid.config import Configurator config = Configurator() config.add_route('xhr_route', '/xhr/{id}') config.add_view('my.package.GET_view', route_name='xhr_route', xhr=True, permission='view', request_method='GET') config.add_view('my.package.POST_view', route_name='xhr_route', xhr=True, permission='view', request_method='POST') config.add_view('my.package.HEAD_view', route_name='xhr_route', xhr=True, permission='view', request_method='HEAD') you get this: config.add_route('xhr_route', '/xhr/{id}') config.add_protected_xhr_views('my.package')
  19. 19. Configuration: extensibility ● All the configuration statements that can be performed in your “main” Pyramid application can also be performed by included packages including the addition of views, routes, subscribers, and even authentication and authorization policies. ● You can even extend or override an existing application by including another application’s configuration in your own, overriding or adding new views and routes to it. from pyramid.config import Configurator if __name__ == '__main__': config = Configurator() config.include('pyramid_jinja2') config.include('pyramid_exclog') config.include('some.other.guys.package', route_prefix='/someotherguy')
  20. 20. Flexible authentication and authorization: the thing you always missed ● Pyramid includes a flexible, pluggable authentication and authorization system. ● Predefined Pyramid plugpoint to plug in your custom authentication and authorization code ● If you want to change these schemes later, you can just change it in one place rather than everywhere in your code.
  21. 21. Declarative security from import Everyone from import Allow class Blog(object): __acl__ = [ (Allow, Everyone, 'view'), (Allow, 'group:editors', 'add'), (Allow, 'group:editors', 'edit'), ] from pyramid.config import Configurator from pyramid.authentication import AuthTktAuthenticationPolicy from pyramid.authorization import ACLAuthorizationPolicy authn_policy = AuthTktAuthenticationPolicy('seekrit', hashalg='sha512') authz_policy = ACLAuthorizationPolicy() config = Configurator() config.set_authentication_policy(authn_policy) config.set_authorization_policy(authz_policy) from pyramid.view import view_config from resources import Blog @view_config(context=Blog, name='add_entry.html', permission='add') def blog_entry_add_view(request): """ Add blog entry code goes here """ pass
  22. 22. Traversal ● Traversal is a concept stolen from Zope ● It allows you to create a tree of resources, each of which can be addressed by one or more URLs from wsgiref.simple_server import make_server from pyramid.config import Configurator from pyramid.response import Response class Resource(dict): pass def get_root(request): return Resource({'a': Resource({'b': Resource({'c': Resource()})})}) def hello_world_of_resources(context, request): output = "Here's a resource and its children: %s" % context return Response(output) if __name__ == '__main__': config = Configurator(root_factory=get_root) config.add_view(hello_world_of_resources, context=Resource) app = config.make_wsgi_app() server = make_server('', 8080, app) server.serve_forever()
  23. 23. View response adapters To follow DRY principle, often you don’t want to repeat returning the Response object from the view def aview(request): return "Hello world!" from pyramid.config import Configurator from pyramid.response import Response def string_response_adapter(s): response = Response(s) response.content_type = 'text/html' return response if __name__ == '__main__': config = Configurator() config.add_response_adapter(string_response_adapter, basestring)
  24. 24. Programmatic Introspection It’s good to have a well-defined mechanism to get back what was registered earlier: views, urls, etc from pyramid.view import view_config from pyramid.response import Response @view_config(route_name='bar') def show_current_route_pattern(request): introspector = request.registry.introspector route_name = route_intr = introspector.get('routes', route_name) return Response(str(route_intr['pattern']))
  25. 25. So what is bad then? ● Probably nothing ● People are worried by ‘complexity’ ● You should always understand what are you doing ● Traversal and security are not easy, but very powerful ● Pyramid is not a monster like Django, you get nothing if you don’t want ● Much less existing packages (but the quality of existing is high)
  26. 26. Thanks for your attention! Questions?
  27. 27. Reference: ● http://docs.pylonsproject. org/projects/pyramid/en/latest/narr/introducti on.html ● framework-shootout/