Blog posts

2016

When alone Kivy is not enough

less than 7 minutes read

Published:

This is my third post, written during my cooperation with Idego Group - (source here)

Abstract:
When one writes non-portable code it has strengths and weaknesses. This particular choice is difficult, because the switch to native API at the beginning of the project may be completely impractical to undo at a later stage. With platform-specific code, one can do virtually anything that the platform is capable of. There are no artificial limits; our Python code has unrestricted access to the same underlying API as the native code. On the downside, depending on a single platform is risky because porting the program to a new system becomes harder with every platform-specific feature one can use.

Grab your free book with Django and Celery

less than 7 minutes read

Published:

This is my second post, written during my cooperation with Idego Group - (source here)

Abstract:
Combination of Django and Celery can be very handy in everyday tasks. We can use different tools for distributing our tasks, both for privileged and unprivileged users, what makes that this idea has a versatile usage.Ask Solem – creator of django-celery and one of the main contributors to Celery still plans new interesting features of his tools. For example, in Celery 4.0 one will be able to execute the task according to sunrises, sunsets etc. It shows that the idea of distributing different kinds of tasks could be all-purpose and still worth research. Most snippets of code from this article can be found at author’s repo.

2015

Chosen aspects of concurrency in Python 3

1 minutes read

Published:

This is my first post, written during my cooperation with Idego Group - (source here)

Abstract:
Although Python fully supports thread programming, parts of the C implementation of the interpreter are not entirely thread safe to a level of allowing fully concurrent execution. GIL that only allows one Python thread to execute at any given time. The most noticeable effect of the GIL is that multithreaded Python programs are not able to fully take advantage of multiple CPU cores (e.g., a computationally intensive application using more than one thread only runs on a single CPU). Threads in Python are great for I/O-bound tasks, but they’re a poor choice for CPU-bound problems. If you are going to use a process pool as a workaround, be aware that doing so involves data serialization and communication with a different Python interpreter. For this to work, the operation to be performed needs to be contained within a Python function defined by the def statement (i.e., no lambdas, closures, callable instances, etc.), and the function arguments and return value must be compatible with pickle. Also, the amount of work to be performed must be sufficiently large to make up for the extra communication overhead. There are many Python modules that support concurrency by means threads and processes. Using them carefully can really speed up your programs.