List of videos

pymove3D Winner Announcement [EuroPython 2014[ [21 July 2014]

Daniel Kraft/Oliver Roch - Using python, LXC and linux to create a mass VM hosting, managed by django and angularjs [EuroPython 2014] [22 July 2014] How we created a scalable mass VM hosting for open source web apps with python, LXC and linux with a web-UI based on django and angularjs. We'll show the underlying architecture of this service, several linux internals that make this possible and we'll talk about bitter failure during development. This talk will be python- and linux-centric with some hints for integrating angularjs into django.

Schlomo Shapiro - Sponsoring Open Source [EuroPython 2014] und damit den Chef überzeugen

Erik Janssens - SQLAlchemy Drill [EuroPython 2014] [23 July 2014] If you have been looking to use SQLAlchemy in one of your projects, but found the documentation a bit overwhelming then this talk is for you. If you have used SQLAlchemy but feel there are some holes in your knowledge of the library, then this talk is for you as well. The idea is that during this talk you bring your laptop with you, and make sure you have SQLAlchemy installed. At the beginning of the talk, we fire up our Python interpreter and start to explore the library in a structured way. In the next 25 minutes, we'll go hands on through the various parts of the SQLAlchemy. We try out the concepts of each part of the library and make sure the basics are well understood. ----- In this talk will introduce the audience to SQLAlchemy in a well structured way, so that basic concepts are understood. This talk will be a combination of slides and interactive code editing in IPython. Both the working of SQLAlchemy as well as best practices in using SQLAlchemy will be demonstrated. I will demonstrate the basic workings of: * the SQL generation layer * the DDL generation * the ORM * the session * transactions The used code will allow those who have their laptop with them to try the code samples for themselves.

Thomas Aglassinger - Solution oriented error handling [EuroPython 2014] [22 July 2014] This talk shows how to use Python's built in error handling mechanisms to keep the productive code clean, derive error messages helpful for the user directly from the code and release ressources properly. ----- Traditionally error handling is regarded an annoyance by developers because it removes the focus from the already difficult enough productive parts of the code to parts that ideally will never be called. And even if, end users seem to be ignore the error messages and just click "Ok" or call the help desk. Solution oriented error handling uses Python's existing try/catch/finally idiom, with statement, assert statement and exception hierarchy in a way that keeps the code clean and easy to maintain. It gives a clear distinction between errors that can be solved by the end user, the system administrator and the developer. Naming conventions and a simple set of coding guidelines ensure that helpful error messages can be easily derived from the code. Most code examples work with Python 2.6+ and Python 3.x, on a few occasions minor differences are pointed out. Topics covered are: 1. Introduction to error handling in Python - What are errors? - How to represent errors in Python - Detecting errors - Delegating errors to the caller - clean resource management 2. Principles of solution oriented error handling - responsibilities between user, admin and developer - when to use raise or assert 3. Error messages - What are "good" error messages - How to derive error messages from the source code - Adding context to the error - How to report errors to the user 4. Solution oriented usage of Python's exception hierarchy - admins fix `EnvironmentError` - users fix `DataError` - representing `DataError` - converting exceptions to `DataError` - developers fix everything else - special Python exceptions not representing errors 5. Template for a solution oriented command line application 6. Best practices for `raise` and `except` - When to use `raise`? - When to use `except`? This talk is a translation of a German [talk](https://github.com/roskakori/talks/tree/master/pygraz/errorhandling) given at the PyGRAZ user group and in a (slightly depythonized variant) the Grazer Linux Tag 2013 ([slides and video](http://glt13-programm.linuxtage.at/events/198.de.html)).

holger krekel - packaging and testing with devpi and tox [EuroPython 2014] [24 July 2014] This talk discusses good ways to organise packaging and testing for Python projects. It walks through a per-company and an open source scenario and explains how to best use the "devpi-server" and "tox" for making sure you are delivering good and well tested and documented packages. As time permits, we also discuss in-development features such as real-time mirroring and search. ----- The talk discusses the following tools: - devpi-server for running an in-house or per-laptop python package server - inheritance between package indexes and from pypi.python.org public packages - the "devpi" client tool for uploading docs and running tests - running of tests through tox - summary view with two work flows: open source releases and in-house per-company developments - roadmap and in-development features of devpi and tox (The presenter is the main author of the tools in question).

Slavek Kabrda - Red Hat Loves Python [EuroPython 2014] [24 July 2014] Come learn about what Red Hat is doing with Python and the Python community, and how you can benefit from these efforts. Whether it is the new Python versions in Red Hat Enterprise Linux via the new Red Hat Software Collections, compatible Python cartridges in OpenShift Platform-as-a-Service (PaaS), or being the leading contributor to OpenStack, there's a lot going on at Red Hat. We're Pythonistas, too!

Floris Bruynooghe - Advanced Uses of py.test Fixtures [EuroPython 2014] [23 July 2014] One unique and powerful feature of py.test is the dependency injection of test fixtures using function arguments. This talk aims to walk through py.test's fixture mechanism gradually introducing more complex uses and features. This should lead to an understanding of the power of the fixture system and how to build complex but easily-managed test suites using them. ----- This talks will assume some basic familiarity with the py.test testing framework and explore only the fixture mechanism. It will build up more complex examples which will lead up to touching on other plugin features of py.test. It is expected people will be familiar with python features like functions as first-class objects, closures etc.

Maximilien Riehl - Practical PyBuilder [EuroPython 2014] [25 July 2014] PyBuilder is a software build tool written in pure python which mainly targets pure python applications. It provides glue between existing build frameworks, thus empowering you to focus on the big picture of the build process. It will be shown through demonstrations and samples how a simple, human-readable and declarative configuration can lead to an astonishingly well-integrated build process which will make maintainers, developers and newcomers happy. ----- # Why another build tool Starting up a simple python project with best practices still takes a lot of boilerplate and glueing (e.G. chaining unit tests and integration tests in the build process, adding a linter, measuring coverage, ...). It often results in extremely ugly homebrew scripts and edge-case solutions that are not reusable. There are even programs out there (e.G. cookiecutter) that encourage boilerplate code generation! # Build orchestration PyBuilder borrows from the *maven* idea of phases (packaging, verifying, publishing, ...) to set up a fully declarative and automated build that can be run locally and remotely (build servers) in the very same way. Rather than reinventing the wheel, it provides glue between existing solutions (like unittest, coverage, flake8, ...) through a simple but powerful plugin mechanism. # The talk After a more theoretical talk with a colleague at PyConDE 2013, I want to show how it's actually like to work with *PyBuilder*. This includes * starting up a project * running builds * using plugins * writing a plugin The demo code will be made available on GitHub and I'll probably have recordings prepped in case something goes wrong. Reviewer FAQ =============== ### How does PyBuilder compare to other existing solutions like zc.buildout? As opposed to solutions like zc.buildout which focus on the *building* of complex projects (many parts, complex dependencies) PyBuilder emphasizes the full build process for very simple projects. Undoubtedly, buildout is more powerful for building in that regard and there is no reason to switch to PyBuilder. However, for simple projects (a few packages, pure python) we believe that PyBuilder is better, especially if you're starting out with Python. The plugin architecture (as opposed to recipes) makes it easier to reason about what is going on. We are able to model dependencies between build phases (like "coverage" needing "unit tests" and "packaging" needing "integration tests") where recipes are not. It also seems (after looking through the recipes available for buildout) that we have more focus on QA as part of the build process (lint code, differentiate between unit/integration tests, code analysis, ...). There is also a special focus on having the build descriptor written in Python (with fluent interfaces where possible) so that it is possible to understand what the configuration is by reading plain english, as opposed to zc.buildout (where the configuration is an ini file, or SCons which is very make-oriented). In the end, a big difference between most build tools and PyBuilder is that PyBuilder is more about orchestration. We didn't reinvent packaging or linting, we simply use what is already there (setuptools, flake8, pymetrics, ...). This allows users to use the tools they want without having to do the integration themselves, and still get a nice, unified build process out of it. A simple example : In buildout, code analysis can be done with ``` [buildout] parts += code-analysis [code-analysis] recipe = plone.recipe.codeanalysis directory = ${buildout:directory}/src ``` This is not readable IMHO. In PyBuilder it can look like this : ``` use_plugin('python.flake8') project.set_property('flake8_include_test_sources', True) project.set_property('flake8_ignore', 'E501') project.set_property('flake8_break_build', True) ``` ### "It provides glue between existing build frameworks" - which ones ? Could you name (some at least) ? Currently there is only a plugin for building with distutils/setuptools. Should that change (e.G. new contender) it would be easy to switch using PyBuilder. Examples where glue is needed : * Glue setuptools + unittest, so that no distribution can be shipped if tests fail * Glue setuptools + coverage + unittest, so that no distribution can be shipped if the statement coverage is too low (configurable ofc) * Glue setuptools + pip so that cloned projects can be built with their dependencies without needing to pip install manually