Piter Py #4

 

Having ready to use solution to common task it's usually a good idea to go on an use it, but sometimes it makes sense to stop and think of how such solution should have been built firsthand. Now we have several libraries helping with building API in Django, most of these are frameworks, with all the vices coming with them: implementation is hidden, code is not written in Python or even Django, but in specially invented dialect/DSL, tasks are solved magically and when they aren't you are in trouble.
In my talk I will use an alternative way - go through the requirements appearing during API implementation and look for simplest possible solution each time, minimizing new abstractions used and especially avoiding inversion of control.

 

I am a freelancer and author of several popular (like funcy and cacheops) and a little bit more unpopular open source libraries and experiments. Looking to get deeper into things in the search of something interesting, intricate and occasionally useful.