Weblog
Michael Bayer: SQLAlchemy
Michael Bayer delivers the keynote on SQLAlchemy at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
"Space Invaders! Relational Modeling! And Domain Models! A mashup."
Computer life
My computer life started in the 1980s with a TRS-80. At school I used that to print Snoopy in ascii art. Then there was the Atari 800. It's still at my parent's house. I started programming on that one, which meant using assembly code. I got as far as creating a cool title screen before giving up.
In the nineties I used Rational Rose for some time to do architectural design. So real waterfall development. But I switch to iterative development to create the real code.
Domain Models
Looking a WordPress code you have request handling, sql statements, e-mailing and html all in one file. This is the water slide model, you just go down the file, without real control.
Compare that to the domain model: a conceptual model of a domain of interest. You model the problem agnostic of implementation details. Create explicit adaptations between the outside world and the model. Keep these adaptations as distinct from each other as possible. You have a request, security concerns, services, data handling, persistence and decide how that interacts with your model. When you paint a picture of this, you get the feeling of a pipeline: you are more in control of how it flows.
Relational Modeling
The relational model represents information as collections of rows, consisting of columns. It allows fluid manipulation of rows organized into sets. It encourages normalized form, to minimize repetition and dependency. It provides declarative query languages such as SQL to access and manipulate data. ACID guarantees.
- Joins: intersection of rows.
- Unions: combine sets of rows.
- Grouping: divide rows into sub groups, apply aggregations.
Imperative programming is what you do in day to day python: "Mr. Computer, open this file -> okay."
SQL is generally declarative. We state our intent. "Mr. Database, give me all the rows in table A that starts with 'Q' -> okay."
How do we reconcile the relational model with the domain model? Represent discrete objects as elements in relational sets, that is: object-relational mapping. Expose "relational geometry" within the object relational mapping system. Automate database tasks, don't hide the database. Allow efficient questions to the database. Consider object instances as table rows. Map compositions to relational structure: an object may have child objects, which in the database is modeled with foreign keys.
Keeping the 'R' in 'ORM'. You should expose relational concepts, otherwise you cannot easily represent some SQL statements. So you should allow nested SELECT statements; subqueries should be possible. It is not good to abstract this away. You should also allow efficient 'questions'. Queries should be combined when possible. Do not do one query and they for each row in the result do an extra query. This is what JOINs are for.
Mashup
Now for the fun part. Warning: Armin thought this was rediculous. We are going to build a space invaders game in Python. It will store the state of the game in a SQLite database in memory.
We have a domain model. Every object you paint on the screen is called a glyph. There are enemy gliphs, player gliphs, message glyphs, etc.
The code uses @hybrid_property so a method can get data back from an instance or get a SQL statement back from a class. Checking whether a missile hits an enemy or an enemy reaches the bottom of the screen, is done using SQL JOINs.
Of course this is all using SQLAlchemy, a Python SQL Toolkit and Object Relational Mapper.
He played a demo game and won, with lots and lots of SQL statements scrolling by. Seriously cool. He will put the code on his blog.
Alexandros Kanterakis: PyPedia
Alexandros Kanterakis talks about PyPedia, at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
PyPedia is the free programming environment that everyone can edit. It uses the Google App Engine (GAE). You can execute Python code on that website. The GAE is a sandboxed, restricted environment, so: no, you cannot delete all files on the system.
Usually, when you search for the solution for some programming problem, you either find a page that executes the code, or you can see the source code but have to download it and run it yourself, or you find documentation. On PyPedia you get all three.
On the home page you see some code, for example this:
Hanoi_towers(5, True)
You can run it right there. Hanoi_towers is an article on the PyPedia wiki. The source code of that article gets executed.
You can create an account, login and create your own articles.
With the pypedia package you can on your own computer import code from the PyPedia website. You can also easily download the code of an article and run it.
You can give other users permission to edit your articles. You can fork articles, just like in github.com.
All content is under the Simplified BSD License.
Good content with unit test can be put in the validated methods section.
You can use PyPedia for open science. A complete analysis can be hosted so your findings can be reproduced. PyPedia offers a REST interface:
www.pypedia.com/index.php?b_timestamp=&get_code=python_code
The python code here must be urlencoded. Other option: run_code.
Future plans: attract communities, add content. Some presentations are planned at conferences.
The code is here: http://github.com/kantale/pypedia
Douwe van der Meij: AOP in Python API design
Douwe van der Meij talks about Aspect Oriented Programming in Python API design at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
Aspect oriented programming is more often used in Java than Python. I have used Java before, so I tried using this concept in Python now.
The use case was BioBench, which is one of the sponsors of this conference. It is an application for biogas installations. A farmer enters measurements and gets info from this.
One aspect you need for your API is security. Also statistics/logging, serialization. Probably more. The danger is that those aspects are scattered all over your code base and are tangled, interweaved with other aspects.
Aspect Oriented Programming means: separating your concerns. Put each aspect in a separate module. How can you implement this in pure python? Decorators!
What is an aspect:
- pointcuts, a signature of your code, a regular expression (though I don't use it in my Python code)
- join points: point in your code where the pointcut expression is true, so where the advices should be run
- advices: code to run before or after the join point, or around it.
The security code is an 'around' advice. If a condition is true, we execute the main code, otherwise we skip it and raise an exception.
So for example you end up with:
@secure @serialize @statistics @dispatch def api_call(...): ...
It is good to apply this for aspects that are orthogonal to your main code, like (mostly) security.
Audience: in Zope you can use zcml for aspect oriented programming.
Miguel Araujo: Django crispy-forms
Miguel Araujo talks about Django crispy-forms at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
In Django forms you can display a form in html in different ways. But it can be hard to customize or to target it using css. You can reorder fields using keyOrder, as fields is a SortedDict. ModelForms are different. You could override templates, but it gets hacky fast.
django-crispy-forms was formerly known as django-uni-forms, created by Daniel Greenfeld. I joined the project in 2010 and became the lead developer.
It has a filter |crispy and a tag {% crispy %}. It adds divs and ids to your form.
With the FormHelper class you control the global form rendering behaviour, using attributes, for example form_method='post', form_action, form_id, form_class, form_tag=False. You can define your own attributes, with the code behind it, to for example have help text as placeholder.
The layout power comes from layout objects. They are Python classes.
Every layout object has an associated class. For example, Div,
Fieldset, HTML. Div(Div('name', 'value'), HTML(" hello
Layouts can be decoupled, and composed into another Layout.
crispy-forms templates can be easily overridden at various levels. There are layout templates and global templates.
There is more power available. Documentation is at http://django-crispy-forms.rtfd.org
Oscar Vilaplana: Tornado in depth
Oscar Vilaplana talks about Tornado at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
You can use tornado for web sockets, streaming, etc. It is a non-blocking web server. You can handle thousands of connections. We is it at PayLogic for something secret.
Three concepts: callback, timeout, event. A callback is something that you want to retun to later. An event is something that happens in a socket. When an event happens, a handler is called. When nothing happens there is a timeout and at the latest then we run the callbacks again. This is all done during an IOLoop.
Handling a web request is coded as some callbacks.
You can keep state around in the code, sharable over all request, so you have less things that you need to build up at the start of a request and have to tear down at the end. This makes it fast.
Push notifications can be done this way.
Audience: Tornado is between Twisted and Django.