Celery is an asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well.
I don’t know about other programming languages, but if you are using Python or Django, you must have heard about Celery quite a few times, and if not, you better look into it. As stated on the project Celery website:
In case of a web service (most common use-case), asynchronous task queues are utilities to push (time-consuming) tasks in background while timely sending back the response for a user request. These delegated tasks can be anything from sending few notifications, dispatching emails, update system logs, or update internal ERP. Having the aforementioned tasks in line with the request processing, can delay the response back to the user to a large extent.
If you’re going through interviews for the positions of Python developer, or looking forward to preparing for one, or just a curios developer, you better have your head clear around the concept of decorators in Python programming language.
I won’t be delving into ‘what are design patterns’ , and why should you make use of it, whenever possible. The post is merely about understanding and writing decorators in Python. You can find plethora of posts about Python decorators, the motivation for me is, that everyone has their own way of explaining, especially a technical concept.
What is Anaconda
Anaconda is a free open-source Python distribution (as well as R programming language), intended for large-scale data processing and analysis, and scientific computing. Anaconda Python distribution is manged and developed by Continuum Analytics.
Anaconda (“Anaconda Distribution”) is a free, easy-to-install package manager, environment manager, Python distribution, and collection of over 720 open source packages with free community support. Hundreds more open source packages and their dependencies can be installed with a simple “conda install [packagename]”. It’s platform-agnostic, can be used on Windows, OS X and Linux. Or even easier.
After writing about ‘what is virtualenv‘ and pyenv I have been feeling a compulsion to write about the one remaining tool in the family i.e. virtualenvwrapper.
As it is in the name, virtualenvwrapper is just a wrapper (an extension) around the virtualenv. The sole motive behind writing it, is covering the discrepancies or features virtualenv lacks, and biggest issue is managing these virtualenvs. As stated in the official docs, the main value-adding features of virtualenvwrapper are:
- Organizes all of the virtual environments at a single location.
- Provides better management of virtualenvs – intuitive commands for creating, deleting, copying virtualenvs.
- A single command to switch between environments i.e. workon (demonstrated later in the post)
- User-configurable hooks for all operations (see Per-User Customization).
- Plugin system for more creating shareable extensions (see Extending Virtualenvwrapper).
You may be a mid-level Python programmer using Python 2.7.5 for sometime, but also curious about Python 3.x.x, or check for yourself what is this all the Python 2 vs 3 debate over Internet, or simply the new functionalities or conventions being introduced in Python 3.x.x. or, just a Python newbie starting off and all so confused given the Python version debate. Don’t worry, my friends you have been rescued – you can keep multiple versions of Python (as many as you like).
There may be lot ways to install multiple Python versions, in the post I’ll be focusing on doing it using penv. – as it’s the most elegant way to do so.
For the starter (this is the opening post for the devopspy.com) let’s start with something basic, something confusing, something you see in almost every python code example i.e. virtual environment.
Python is an interpreted language, and for development all we need is a Python interpreter (included in Linux based OS – for Windows can be installed using the provided .msi). Like other programming languages Python has its own way of enhancements i.e. to use functionality not there by default, all we have to do is install the package, using any installation utility – pip (most common way), easy_install, or manual installation. These installed packages may termed as the requirements or the dependencies. These dependencies vary for every project – to get a project working all we need is the environment setup ( i.e. Python and the dependencies installed).
What is a virtual environment ?
is basically a separate Python interpreter with its own set of installed packages. As mentioned above the Python interpreter along with the installed packages make the environment – so we can have multiple Python environments on a single machine, the environments other the default are termed as virtual environment, which we need to create and activate before we can use (demonstrated later).