This summer I had the chance to attend EuroPython. Over 1100+ Python fans were able to make the most out of the lively week.

It was my first time at this amazing conf. I fully enjoyed it and learned lots of new stuff. Read on to learn about reviewing code, the Pytest library, and other friendly tools to help you improve your command of the language.

EuroPython 2016, took place in Euskalduna Jauregia, Bilbao (Basque Country) on July 17-24. The venue was a spacious and cozy place.


Code Reviews

Dougal Matthews and Adam Dangoor both gave awesome talks on the subject of Code Reviews.

Both are active contributors to Open Source projects and provided many recommendations on how to contribute to a project. I fully agree with their advices to demystify the classic picture of code reviews.

In a traditional code review, someone reads another’s code just to find bugs. The modern view is to perform reviews as an open conversation about code, where knowledge is shared and teamwork is the primary motivation.

Author’s Steps

Follow project guidelines.
Take advantage of the fact that nearly all projects have defined guidelines for contributors (e.g., rules, style, testing, etc.)
Read the requirements.
A good practice is to do some prior research about what there is to be done and how to achieve. If need be, talk to the project maintainer about priority of tasks.
Keep small changes.
Focus on the topic and work on small patches. Long code is difficult to read and easier to miss something important.
Provide context.
Make an effort to write good comments and Pull Requests. Be sure to answer the what, why, and how questions.
Start the conversation.
Seed nicely the discussion and invite feedback.

Tips for the Author

Write reviewable code.
Clean code is easier to review. Write code keeping in mind that somebody else will read it.
Be descriptive.
Good descriptions about your changes make them understandable.
Be open to feedback.
Respect comments and don’t take them personal.
Don’t be too proud.
Be ready to listen to improvements. Masterpieces are the rare exception.

Reviewer’s Steps

Read the requirements.
An issue tracker may be handy.
Check same interpretation.
Assure that both the author and the reviewer have interpreted the spec in the same way. Otherwise, if there is something ambiguous, contact the author of the issue.
Check CI.
Check to be sure that there are no new issues in the continuous integration tool.
Check that requirements are implemented.
If the issue is a bug, the related tests should pass. If the issue is a new feature, the related tests should cover all use cases.
Check existing implementation.
Verify that new changes don’t affect the existing functionality.
Check maintainability and documentation.
Determine if the code is easy to maintain, if it is documented, and if the contribution guidelines have been followed.
Continue the conversation.
Comment on anything that may have appeared in the previous steps or that might be improved. Ask questions if something is unclear.
If the reviewer is the maintainer of the project, he has the responsibility to decide whether to merge the submitted changes or not.

Tips for the Reviewer

Keep project guidelines.
If not, two reviewers might have different feedback and this is not desirable for the author.
Stay fresh while reading.
Long time reviews might cause some spots to be left uncovered.
Be polite.
Instead of telling, ask new ways of implementation.
Don’t be rude.
Always say at least one good thing.
Be grateful.
Point out what you learned and say thanks.


One of the most interesting and useful workshops at EuroPython was given by Florian Bruhin about the pytest testing framework for Python. It is already being used in big projects like PyPy, Django REST Framework and JupyterHub.

Florian’s lectures and code examples were very helpful in getting to know the library and the way it works internally.

Main features

From simple to complex tests.
Unit and functional tests are welcome.
Easy to use.
On the basic scenario, you just place an assert statement and chill.
Detailed assertion introspection.
When a test fails, intermediate values for many different objects are inspected and shown.
Automatic discovery of tests.
There are default rules so that tests under a given directory are discovered automatically. These can be edited.
Good management of fixtures.
Fixtures can be reused and overridden at different scopes.
Support for marking.
Metadata can be added to test functions.
Support for other frameworks.
The unittest and nose tests can be run.
Broad plugin architecture.
There is an active community improving the core with plugins for popular projects like Django and Flask.
Colorful output.
Nice visualization of failures.
Integration with CI.
JUnit XML reports can be generated.
Configuration options.
Numerous session settings can be customized.

An Example with Fixtures

A functionality that I loved is the support for test fixtures. Especially, they make it easy to create and use custom objects needed in different tests, leveraging decorators, and performing modular and reusable code.

Here we have a snippet to define the connection to a MongoDB server without writing setup/teardown functions. It divides the implementation details and the logic.

I look forward to continuing my research of this valuable tool that is pytest and diving into its internals.


Other Fascinating Tools

I really enjoyed learning about new interesting tools and I will briefly introduce three of them: the Project Jupyter’s main instruments, the Xonsh shell, and the Conda package manager.


Would you like to have system commands available in the Python shell at any time? Would it be useful to get the code of a module just by typing two question marks?

This functionality, among many others, are included in IPython, an improved interactive Python shell, including,

  • Object introspection
  • Persistent history
  • Input and output caching
  • Magic commands
  • Colorful
  • Embeddable in GUIs
  • Parallel computing tools

IPython is also the reference kernel for Jupyter Notebook, a web application where users can create, share, and collaborate through documents. It supports text, code, equations, and visualizations.

I find it very suitable for educational purposes, take a tour.

Moreover, ever since IPython and Jupyter were divided in kernel and notebook respectively, many more kernels have been developed. This means that code from other languages can be run in the notebook.


Wouldn’t it be nice to write Python code directly on the command line shell?

Thanks to the parsing of two different syntaxes, IPython and Bash, Xonsh shell language lets you write and mix Python code and system commands. This is somehow opposite of what IPython offers, performing without magic commands.

It has common functionality shared by main shells as well.

I’ve been playing around with this shell and it shows up like an astonishing option. Besides, it has support for environment variables (it handles them like Python variables) and for Git branches.

During the amusing Lightning Talks one of the attendees gave an incredibly fast tour through several shells, showing Xonsh’s advantages.


Have you ever been in trouble while installing some Python module with pip, getting missing library errors?

Very popular in the data science community, Conda introduces itself as a package manager with the ability to install already compiled packages. These binaries are built and published not only by Continuum, the company behind Conda, but also by contributors.

The dependency management is great (you know in advance the precise package versions to install), and the virtual environment, completely isolated from the system also holds non-Python dependencies.

One of the great features is the possibility to export and share environment descriptions, even between distinct platforms.

If you feel like checking some syntax or a fix included in a specific version of a library, give Conda a try.

And Finally…

EuroPython 2016 was organized in a very smooth way. Many people worked hard to get things done. The schedule was enormous, with many talks, trainings, and panels.

Fortunately, all of the talks were recorded and published.

A lot of Pythonists from different backgrounds gathered to learn and share knowledge. We had a sense of community, with many opportunities to exchange experiences, learn about the state of the art, ask questions, give answers, taste local food, code, and definitely, have fun!