List of videos

Mikey Ariel - FOSS DOCS 101 (keep it simple, present!) [EuroPython 2015] [24 July 2015] [Bilbao, Euskadi, Spain] Does your open source project need better documentation? Do you wish that new users could get started with your software more easily? Do you feel that your code contribution workflow isn't documented well enough, or that contributors are discouraged from documenting their code? How can you give your project docs the love they deserve? This high-level talk aims to introduce the main principles of technical communication in the context of FOSS projects. It is intended for anyone who interacts with docs, whether your project is fresh off the dev environment or has been around since the dawn of Git. Topics include tone, style, process management, structure, and contribution workflow.

Takayuki Shimizukawa - Sphinx autodoc: automated API documentation [EuroPython 2015] [20 July 2015] [Bilbao, Euskadi, Spain] Abstract: Using the automated documentation feature of Sphinx, you can make with ease the extensive documentation of Python program. You just write python function documents (docstrings), Sphinx organizes them into the document, can be converted to a variety of formats. In this session, I'll explain a documentation procedure that uses with sphinx autodoc and autosummary extensions. Description: Sphinx provides autodoc feature that generate document from docstring in your python sources. The docstring that contains description and example of the use of function written near the program, makes doc easy to update. In addition, the output of the Sphinx will make you understand what to write in docstring. As a result, this will improve your motivation of doc writing. To use the autodoc, you must specify python modules to automodule directive one by one. This is a tedious task, hoswever autosummary extension automate this task. In most cases, once developers have developed the API, you only need to run the make html of Sphinx, you get a nicely formatted document. Sphinx also has coverage and doctest extentions. These support writing the documentation to work with autodoc. This allow you to check the APIs that have not been documented or you can verify each doctest part is correct or not. If you use such autodoc-related extensions, you can create a Sphinx API documentation in the following procedure. 1. make coverage; you can get the APIs that have not been documented. 2. Write docstrings that includes the doctest format how to use the API. 3. make doctest; you can verify each doctest part is correct or not. 4. make html; you can generate the HTML or your favorite format. In this session, I'll explain a documentation procedure that uses with sphinx autodoc, autosummary, coverage and doctest extensions. Target: - Python programmer who is struggling with documentation. - Python library author who want to generate API docs automatically. - Python library author who want to create a clear documentation which contains python snippets. Outline: * Self introduction (2 min) * Sphinx introduction (2 min) * What is Sphinx? * Sphinx examples * Have you written API docs for your code? (2 min) * I don't know what/where should I write. * Docstrings is needed? Are there some specific format? * Getting start Sphinx (2 min) * How to install Sphinx * How to start a Sphinx project * Generate API docs from your python code (5 min) * setup autodoc extension * write docstrings for yuor python module * "automodule & make html" will generate API docs from python code * autodoc pros & cons: docs for many modules * Listing APIs automatically (5 mins) * setup autosummary extension * how to use autosummary directive * no more autodoc directive * Discovering undocumented APIs (5 min) * setup coverage extension * make coverage * Detect deviations of the impl and doc (5 min) * setup doctest extension * make doctest * Overall picture, tips, Q&A (10 min) * Overall picture of the process * Options for autodoc * translate them into other langs

Vlad Temian - gitfs - building a filesystem in Python [EuroPython 2015] [23 July 2015] [Bilbao, Euskadi, Spain] gitfs is an open-source[1] filesystem which was designed to bring the full powers of Git to everyone, no matter how little they know about versioning. A user can mount any repository and all the his changes will be automatically converted into commits. gitfs will also expose the history of the branch you’re currently working on by simulating snapshots of every commit. gitfs is useful in places where you want to keep track of all your files, but at the same time you don’t have the possibility of organizing everything into commits yourself. A FUSE filesystem for git repositories, with local cache. In this talk we will take a look at some of the crucial aspects involved in building a reliable FUSE filesystem, the steps that we took in building gitfs, especially in handling the git objects (http ://git-scm.com/book/en/v2/Git-Internals-Git-Objects), what testing methods we have used for it and also we will share the most important lessons learned while building it. The prerequisites for this talk are: A good understanding of how Git works Basic understaning of Operating Systems concepts [1] You can get the source here - https://github.com/PressLabs/gitfs; you cand find more details here - http://www.presslabs.com/gitfs/.

Fabian Kreutz - TDD - the why, the how and the when not [EuroPython 2015] [23 July 2015] [Bilbao, Euskadi, Spain] TDD is great, we all know that. But why is it so, and under which circumstances is it ineffective or even harmful? In this talk I want to delve into the deeper meaning of testing to derive how to do it best. All of this from the point of view of somebody who has profited but also struggled with testing and TDD. For every experience level from beginner to advanced there is something to learn or ponder.

Paul Hallett - What it's really like building RESTful APIs with Django [EuroPython 2015] [23 July 2015] [Bilbao, Euskadi, Spain] At the beginning of this year I started working at Lyst and I was tasked with helping to replace their old and outdated web API with a modern RESTful replacement. Along the way we encountered some interesting design decisions and now I’m going to share what we learned about building a real RESTful API with Django and Django REST framework. I've been talking about how to build great RESTful APIs for the past year at various Python and Django conferences in Europe. Now I'd like to take some real world experiences from creating Lyst's new web API and share what I've learned along the way.

Claudiu Popa - 12 years of Pylint (or How I learned to stop worrying about bugs) [EuroPython 2015] [22 July 2015] [Bilbao, Euskadi, Spain] Given the dynamic nature of Python, some bugs tend to creep in our codebases. Innocents NameErrors or hard-to-find bugs with variables used in a closure, but defined in a loop, they all stand no chance in front of Pylint (http://pylint.org/). In this talk, I'll present one of the oldest static analysis tools for Python, with emphasis on what it can do to understand your Python code. Pylint is both a style checker, enforcing PEP 8 rules, as well as a code checker in the vein of pyflakes and the likes, but its true power isn't always obvious to the eye of beholder. It can detect simple bugs such as unused variables and imports, but it can also detect more complicated cases such as invalid arguments passed to functions, it understands the method resolution order of your classes and what special methods aren't implemented correctly. Starting from abstract syntax trees, we'll go through its inference engine and we'll see how Pylint understands the logical flow of your program and what sort of type hinting techniques are used to improve its inference, including PEP 484 type hints. As a bonus, I'll show how it can be used to help you port your long-forgotten library to Python 3, using its new --py3k mode. Link to presentation: http://pcmanticore.github.io/pylint-talks/#slide:1

Armin Rigo - The GIL is dead: PyPy-STM [EuroPython 2015] [23 July 2015] [Bilbao, Euskadi, Spain] Take a big, non-multithreaded program, and run in on multiple cores! PyPy, the Python implementation written in Python, experimentally supports Software Transactional Memory (STM). It runs without the Global Interpreter Lock (GIL). The strength of STM is not only to remove the GIL, but to also enable a novel use of multithreading, inheritently safe, and more useful in the general case than other approaches like OpenMP. The main news from last year's presentation is that there is now a way to get reports about the "STM conflicts", which is essential to go past toy examples. With it, you can incrementally remove conflicts from large code bases until you see a benefit from PyPy-STM. The goal of the talk is to give several concrete examples of doing that.

Jyrki Pulliainen - How-To: Build a local Python community [EuroPython 2015] [24 July 2015] [Bilbao, Euskadi, Spain] Do you like visiting Python conferences like the EuroPython? Does it make you to want something similar where you live too? This talk looks into the effort, practical things and some good tips on how to bootstrap your own Python community where you live! If you already run a local Python community, join this talk to share your views and give your comments to those interested in building their first Python community. After the talk you have a good idea of what it takes to run your local Python community (spoiler: not much!) and how can you take it even further!

Ignacio Elola - Everyone can do Data Science in Python [EuroPython 2015] [20 July 2015] [Bilbao, Euskadi, Spain] Data Science is a hot topic, and most data scientist use either Python or R to do their jobs as main scripting language. Being import.io data scientist for the last 2 years, all of them using Python, I've come across many different problems and needs on how to wrangle data, clean data, report on it and make predictions. In this talk I will cover all main analytics and data science needs of a start-up using Python, numpy, pandas, and sklearn. For every use case I will show snippets of code using IPython notebooks and run some of them as live demos.