At the end of October there was a Python conference in Munich (PyMunich). For a regional conference it was quite big in my opinion. There were 3 tracks and more then 40 speakers.
As always I won’t cover all the talks just the ones that I found the most interesting and educational. After all this is the biggest reason why I go to these conferences.
The first talk I attended was by Dmitry Trofimov. He talked about profiling (“Profiling the unprofilable“). There are 2 approaches you can profile your code and it is important to know them both so you know which one to choose. The first one is statistical or sampler profiling (e.g. vmprof) and the second one is deterministic profiling (e.g. cprofile). For more details about the differences I strongly suggest to do some research on your own.
When you need to optimize your code you should be aware of the optimization levels. Often developers want to be smart and they go straight into optimizing their algorithms. But this doesn’t have the biggest impact. The biggest impact on the performance has the design (architecture). So this should be your biggest focus. After that you can start looking at algorithms and data structures and at the end line profiling. See “Effective Python” section in lessons learned from europython 2016 blog post for more details on this.
You can also use Cython for even better optimization (i.e. when you would need to write C code) but in most cases this isn’t necessary when building for the web because the bottleneck is network I/O. Stefan Behnel had a great talk about “Getting Native with Cython” and he showed us how easy it is to write pure python code and then transform it to Cython. If you have performance issues and you have already done all the optimization you could think of I strongly suggest to try with Cython. I realise that it is probably harder than Stefan showed us but still it is worth looking into in my opinion.
Encryption is awesome. We all like it, but are we all using it? I admit that I don’t have it on my site but I should. And now with Let’s Encrypt Certificate Authority there are no more reasons why any of us don’t use encryption on their site(s). Markus Holtermann who had a talk about SSL encryption (“SSL all the things“) pointed out a few things that we should probably all know:
- SSL 2 and 3 are broken, so don’t use them,
- also don’t use TLS 1.0/1.1,
- get fresh certificate every 90 days,
- disable (make redirect) http because it can leak some information you don’t want.
There are many open source tools that can help you achieve nice and tidy encryption on your site. One of them is `acme-tiny` (https://github.com/diafygi/acme-tiny). It is very small script (less than 200 lines) which means you can easily read every line of the code which you should because you need to trust this tool with your private keys.
The last talk I want to mention was by far my favourite one. Philip Bauer showed us how to debug like a pro (“Debug like a pro. How to become a better programmer through pdb-driven development“).
His bread and butter tool is `pdbpp` or `pdb++` which is a drop-in replacement for `pdb`. This means that you create break point just like with pdb but if you have pdb++ installed it will automatically get called instead.
Here are the basic commands for pdb that Philip highlighted:
- l[ist] (list source code of current file)
- n[ext] (continue execution until next line)
- s[tep] (execute the current line, stop at the first possible occasion)
- r[eturn] (continue execution until the current function returns)
- c[ontinue] (continue execution, only stop when a breakpoint is encountered)
- w[here] (show stack trace, recent frame at bottom)
- u[p] (move up the stack)
- d[own] (move down the stack)
- b[reakpoint] (set a new breakpoint. `tbreak` for temporary break points)
- a[rgs] (print the argument list of the current function)
The nice thing about pdbpp is that it has a long list method (`ll`) which displays the whole function you are in (Note: ipdb also has long list method).
Other python debugging tricks you should know about are:
- use
?for getting additional information lib/class/function/… (e.g.os?) - use
??for displaying the source code of the lib/class/function you want to inspect (e.g.os.path.join??) pp(Pretty-print) is already in pdb so you should always use itpp locals()will pretty print local variables
One of the best tricks is the `help` function which accepts object and returns generated help page for the object. !help(obj.__class__)command will generate help page which will contain all the methods including class methods and static methods with docstrings, method resolution order, data descriptors, attributes, data and other attributes inherited and much more.
Note: The reason you need to put ! before help function in pdbpp/ipdb is because is you don’t put ! you will call pdbpp/ipdb internal help function which is not the python build-in help function.
You can also use --pdboption when running unit tests with pytest or nosetest and this will cause to drop in a pdb whenever a test fails or errors. From there you can write a code that will pass a test, copy paste that code into your file and you are done. This is the basic principle of Test-Driven / Debug-Driven Development (TDD).
Any questions? Send us an email.
