OOP concepts in Python 2.x - Part 2

Abstract

This post continues the analysis of the Python OOP implementation started with this post, which I recommend reading before taking on this new one.

This second post discusses the following OOP features in Python:

  • Polymorphism
  • Classes and instances (again)
  • Metaclasses
  • Object creation

This post refers to the internals of Python 2.x - please note that Python 3.x changes (improves!) some of the features shown here. You can find the updated version here.

Good Morning, Polymorphism

The term polymorphism, in the OOP lingo, refers to the ability of an object to adapt the code to the type of the data it is processing.

Polymorphism has two major applications in an OOP language. The first is that an object may provide different implementations of one of its methods depending on the type of ... more


OOP concepts in Python 2.x - Part 1

Abstract

Object-oriented programming (OOP) has been the leading programming paradigm for several decades now, starting from the initial attempts back in the 60s to some of the most important languages used nowadays. Being a set of programming concepts and design methodologies, OOP can never be said to be "correctly" or "fully" implemented by a language: indeed there are as many implementations as languages.

So one of the most interesting aspects of OOP languages is to understand how they implement those concepts. In this post I am going to try and start analyzing the OOP implementation of the Python language. Due to the richness of the topic, however, I consider this attempt just like a set of thoughts for Python beginners trying to find their way into this beautiful (and sometimes peculiar) language.

This first post covers the following topics:

  • Objects and types
  • Classes and instances
  • Object members: methods and attributes
  • Delegation: ... more

Digging up Django class-based views - 3

This post refers to Django 1.5. Please be warned that some of the matters discussed here, some solutions or the given code can be outdated by more recent Django versions

In the first two issues of this short series we wandered around the basic concepts of class-based views in Django, and started understanding and using two of the basic generic views Django makes available to you: ListView and DetailView. Both are views that read some data from the database and show them on a rendered template.

This third issue wants to introduce the reader to the class-based version of Django forms. This post is not meant to be a full introduction to the Django form library; rather, I want to show how class-based generic views implement the CUD part of the CRUD operations (Create, Read, Update, Delete), the Read one being implemented by "standard" generic views.

A very basic example

To start working with CBFs (class-based forms) let's say we are working with ... more


Digging up Django class-based views - 2

Abstract

This post refers to Django 1.5. Please be warned that some of the matters discussed here, some solutions or the given code can be outdated by more recent Django versions

In the first installment of this short series, I introduced the theory behind Django class-based views and the reason why in this context classes are more powerful than pure functions. I also introduced one of the generic views Django provides out-of-the-box, which is ListView.

In this second post I want to talk about the second most used generic view, DetailView, and about custom querysets and arguments. Last, I'm going to introduce unspecialized class-based views that allow you to build more complex Web pages. To fully understand DetailView, however, you need to grasp two essential concepts, namely querysets and view parameters. So I'm sorry for the learn-by-doing readers, but this time too I'm going to start with some pure ... more


Digging up Django class-based views - 1

Abstract

This post refers to Django 1.5. Please be warned that some of the matters discussed here, some solutions or the given code can be outdated by more recent Django versions

Django programmers that started with versions prior to 1.3 are used to deal with views as functions, and they learned how to process even complex forms in a procedural way. From the release 1.3, Django introduced class-based views (CBVs) and ported its powerful generic views to this new paradigm (class-based generic views, or CBGVs).

This change, however, has not been harmless for Django novices: the django-users mailing list and StackOverflow are full of questions about views and classes, and the official documentation on this topic is still a little unorganized. Well, open source things are always ready to be improved, aren't they? This post aims to share some thoughts and insights about CBVs, and hopefully it can also lead to an improvement of the official documentation.

I want to thank ... more


Some tips about AMQP direct exchanges

EDIT: thanks to Alvaro Videla that pointed out that a queue can be connected to more than one exchange; sorry for the wrong information.

Everyone who started using AMQP learned from the very beginning that there are three different types of exchanges, namely direct, fanout and topic. In this post, I am going to highlight some interesting properties of direct exchanges, which were not clear to me when I started using RabbitMQ.

Now some time has passed since I started, and reading the RabbitMQ tutorials again I can see that these properties are no mystery. However, in this short post I want to clearly point out three different uses of direct exchanges, in the hope that other novices will be helped to better understand those powerful components of an AMQP system.

Movie cast

The cast of an AMQP message delivery is made of three different type of components: the exchange, the queues, and the consumers.

The ... more


Postage - a RabbitMQ-based component Python library

Pika is a wonderful pure Python implementation of the AMQP protocol. Using it you can exploit the full power of your RabbitMQ installation from your Python code.

When using pika to develop a component-based system I tried to write some code to simplify its use: the result is Postage, a Python library that provides higher level structures such as a message format, components fingerprint, rich producer and consumers.

Most notably it provides a handler mechanism for consumers that makes message processing a breeze.

Postage is freely available under the GPL2. It is based on the pika BlockingConnection since I had no experience with other adapters. If you want to hack it, feel free to fork it on Github and submit a pull request.

A simple ping example

I'll describe here a very simple example of a producer/consumer system using ... more


libqgit2: a Qt wrapper for libgit2

Libgit2 is "a portable, pure C implementation of the Git core methods" started in 2008 by Shawn O. Pearce. It is successfully used in both commercial an open source projects and wrapped in many languages (among the others Ruby, C#, Python). In 2011 Laszlo Papp from KDE started the libqgit2 project, aiming to port libgit2 features to C++/Qt. Sadly, lately the development slowed down a little and the library could not compile against the latest libgit2.

Being interested in using libgit2 in Qt/KDE projects, I am trying to restart the development. I managed to update the library to libgit2 0.19.0 (latest version), and you can find the code on GitHub. Feel free to fork it and work on it, but remember that this is just an unofficial repository.

Official repository is hosted by KDE Projects and I'm managing to update it ... more


The Lord of the Rings: an Erlang epic

Abstract

One of the first really challenging problems an Erlang novice must face is the classical process ring, which can be found around the Internet and most notably in "Erlang Programming" by Cesarini and Thompson (page 115).

Its formulation may vary, but the core of it requires the programmer to design and implement a closed ring of processes, to make them pass a given number of messages each other and then terminate gracefully.

I try here to give an in-depth analysis of the matter, to point out some of the most interesting issues of this exercise. I strongly suggest the Erlang novice to try and solve the exercise before looking at the solutions proposed here.

Linking processes

The aim of the exercise is to build a chain of processes that exchange messages. This latter specification is important since we are required to connect our processes with the only purpose of sending messages and we know that, in Erlang, a process may send a message to another process ... more


Error handling in Erlang - a primer

Abstract

This article aims to summarize Erlang error handling both in sequential and in concurrent environments. The targets of this article are novices that, like me, make their first steps into the beautiful world of Erlang. Moreover, I always find that trying to explain things makes me understand them better.

Disclaimer (for Erlang gurus): I'm a complete Erlang novice so please be indulgent with me while you read my thoughts. Corrections and suggestions are welcome!

Introduction

Recently I started studying Erlang; coming from a pure imperative background (C, C++, and Python) I have to say that Erlang has been a surprise and a joy. I did not find something so innovative since long, even if the pure functional part of the language was not totally new since it is available in Python too.

The concept of runtime system, with a support for concurrency built in the language itself, the pattern matching idea and the recursion as a way to implement loops are all ... more