Modularising your shell config for a cleaner setup

Note: The setup described in the following sections can be applied to shells like bash, zsh, fish and other common unix shells. However, keep in mind that the command(s) might differ a bit.

I’m using custom shell commands, aliases, and functions quite heavily. As my .bashrc and .zshrc grew too big, I decided to mudularise my config and want to share with you how I’ve done it.

First of all, I’ve created a dedicated directory in my root directory for all of my custom shell commands, aliases, and functions:

$ mkdir ~/.shell_config

Inside of the directory I created dedicated files per topic. My current .shell_config directory looks like this:

$ tree ~/.shell_config
/home/florian/.shell_config
├── application_aliases
├── directory_aliases
├── enhanced_shell_commands
└── git_aliases

0 directories, 4 files

The definition of one of these files is pretty straightforward:

$ cat ~/.shell_config/application_aliases
alias python3.9="/home/florian/workspace/python/cpython/python"
alias python="python3.8"
alias open="xdg-open"

alias build_latest_python="cd /home/florian/workspace/python/cpython && git pull && make && make test"

function pycharm() {
    /usr/local/bin/pycharm-2019.2.3/bin/pycharm.sh "$1" </dev/null &>/dev/null &
}

Finally, add the following line to your .bashrc , .zshrc or whatever your shell config file is called to automatically load all files inside the .shell_config directory:

for f in ~/.shell_config/*; do source $f; done

And that’s it! Congratulations, you’ve modularised your shell config! If you want to get a list of useful unix commands, aliases and functions I’m currently using, visit my useful-unix repository over at GitHub. Stay curious and keep coding!

Solving the black screen Screen Capture (XSHM) issue occurring under Debian

Recently, I wanted to use OBS Studio (Open Broadcast Software) to record some of my coding sessions. As I switched from Windows to Debian a lot of things are still new to me.

As I followed along there (unofficial) build instructions, I got OBS Studio up and running except the most important feature: Screen Capture.

That’s why I also tried building it from source and installing it via snap. However, audio and Window Capture just worked fine, but the Screen Capture did not.

It seemed to be a display server related problem (Again, I’m fairly new to Linux), that’s why I specifically searched for terms I already came across during my search: Wayland and X11.

After reading a few user reports I conclude, that OBS is not working well together with Wayland. In fact, you won’t get OBS running properly on operating systems using Wayland as a display server protocol. However, most users revealed, that using X server helps.

The loginctl command showed me, which type of display server protocol I was using: Wayland.

A bit of researched revealed, that I simply needed to uncomment a single line in a configuration file to force my Debian system to use X11, which is already installed, instead of Wayland.

Simply go to /etc/gdm3/daemon.conf and uncomment the line containing WaylandEnable (at my system it was line 7) so it looks like this:

# GDM configuration storage
#
# See /usr/share/gdm/gdm.schemas for a list of available options.

[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false

# Enabling automatic login
#  AutomaticLoginEnable = true
#  AutomaticLogin = user1

# Enabling timed login
#  TimedLoginEnable = true
#  TimedLogin = user1
#  TimedLoginDelay = 10

[security]

[xdmcp]

[chooser]

[debug]
# Uncomment the line below to turn on debugging
# More verbose logs
# Additionally lets the X server dump core if it crashes
#Enable=true

Note: Depending on your setup the directory might be /etc/gdm/ and the configuration files name might be different as well. Please also keep in mind, that you need to reboot your system before changes take effect.

I hope this short article helps you on your own setup — keep coding!

After publishing my last article, which was about list.sort() and sorted(list), I was asked, why I was using the boxx library instead of built-in functionalities to measure the execution time of certain pieces of code. I responded, that it’s only personal preference and that you can simply create your own context manager measuring the execution time of code pieces.

In this article I will show you how to create your own timing context manager. Furthermore, different ways to accomplish that are covered.

Time Measurement

What’s already available?

Python provides you different ways to measure the execution time. For instance you can use Python’s built-in timeit module to measure the execution time of small pieces of code.

>>> import timeit
>>> timeit.timeit('"-".join(str(n) for n in range(100))', number=10000)
0.3018611848820001

However, the timeit.timeit function only accepts strings. This can be quite annoying if you want to measure larger functions. The following example is from the official Python documentation and shows you, how you can run and measure functions using the timeit module.

Although it works, it does not look really pythonic.

Another way to measure the execution time is to make use of Python’s built-in cProfile module. However, this is not recommended! It’ s simply a workaround to get a sense of how long certain code pieces need to be executed. In fact it’s not really precise. You can use it via:

>>> python -m cProfile <file_name.py>

Now that we have seen a recommended but unpythonic, and a discredited and unpythonic way, how can we implement our own recommended and pythonic solution?

The Idea

The idea is quite simple: We take the time at the beginning of the execution and subtract it from the time at the end of the execution. Fortunately, Python has a built-in module we can use: time .

>>> import time
>>> start = time.time()
>>> # do some stuff
>>> end = time.time()
>>> print(f"Elapsed Time: {end - start}")

Great! However, adding one line of code before and two lines after a code piece we want to measure is an overhead I don’t want to have. So let’s create a context manager for that.

Creating A Context Manager

There exist different ways to create a context manager in Python. We will have a look at two ways to accomplish that: A class-based and a generator-based context manager.

Class-based Context Manager

To create a class-based context manager, the dunder methods __enter__ and __exit__ need to be implemented. The first one is called when entering a context (manager), the latter is called when leaving the context.

With this knowledge we can create a Timer class implementing both methods. When entering the context, we want to get the current time and save it to a start instance variable. If we leave the context, we want to get the current time and subtract the start time from it. The result is printed.

To customize the output, we let the user specify a description, which is printed before the elapsed time. The following gist shows you the ready-to-use class.

Generator-based Context Manager

The generator-based approach is a bit more straightforward. Basically, we create a generator function containing the program flow (taking start and end time as well as printing the elapsed time). The @contextmanager decorator turns the generator function into a proper context manager by wrapping the generator by the GeneratorContextManager object.

Let’s describe it a bit less formal: What happens is, that entering the context (timing) results in taking the current time and playing the ball back to the code inside the context using yield . If the code inside of the with -block is executed, we jump back to the point right after the yield keyword. Now we calculate the elapsed time and print it. We are now leaving the context.

Summary

In this article you learned how to create your own timing context manager. After creating the basic concept, you implemented the context manager in two ways: Class-based and generator-based. The resulting class and generator function are ready-to-use.

I hope you enjoyed reading this article and learned something new. Feel free to share this article with your friends and let me know what you think about the discussed approaches in the comments. Stay curious and keep coding!

References

https://book.pythontips.com/en/latest/context_managers.html
https://docs.python.org/3/library/contextlib.html

📝 Read this story later in Journal.

🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories, opinions, and news waiting in your inbox: Get the noteworthy newsletter >

A closer look at Python’s built-in List Sorting Methods concerning Memory Consumption and Time Efficiency

Introduction

Recently, I came across the question, which method to sort a list is more efficient: Using Python’s built-in sorted function or relying on the list.sort method. To answer this question I started a little investigation described in this article. You can find the repository I’m referring to on GitHub.

The starting point is a Python list containing 1.000.000 random numbers (integers) built using the random module:

import random

arr = [random.randint(0, 50) for r in range(1_000_000)]

The generated numbers are in the range from 0 (inclusive) to 50 (inclusive).

Memory Consumption

Let’s have a look at the memory consumption of both functions. Therefore, we are using the builtin resource module to track the maximum memory usage. As the resource module enables us to track the memory usage of a single thread, we are running the sorting of our list in a separate thread. You can use the FunctionSniffingClass included in the repository to do so.

Let’s have a closer look at our Python script:

We create two wrapper functions for the built-in ones to be able to pass them as arguments to the FunctionSniffingClass . We could pass the built-in sorted function directly to the FunctionSniffingClass , but we want the same chances for both built-ins. Furthermore, some simple command-line argument parsing is implemented to be able to use it as simple as possible from the command-line.

Curious how both built-ins perform? Let’s see!

$ python memory_measurement/main.py sort
Calling the Target Function...
Function Call Complete

MAX Memory Usage: 23.371 MB

$ python memory_measurement/main.py sorted
Calling the Target Function...
Function Call Complete

MAX Memory Usage: 30.879 MB

As you can see, the sorted function consumed around 32% more memory as the list.sort method. This was predictable as the latter on modifies the list in-place, whereas the first ones is always creating a separate list.

Speed

To be able to time the execution time of both wrapper functions, we make use of the third-party boxx module. The following gist shows you how we can make use of its timeit function to time the execution time of both functions.

Note: Be sure to run the sorted_builtin function first as the list.sort method sorts the list just in-place, so the sorted function wouldn’t have to sort anything!

Running the above snippet prints the following output:

$ python main.py
"sorted(list)" spend time: 0.1104379
"list.sort()" spend time: 0.0956471

As you can see, the list.sort method is slightly faster than the sorted function. Why is this the case? Let’s disassemble both functions and see, whether we can conclude the answer based on the bytecode:

Both functions bytecode is pretty much the same. The only difference is, that the list_sort function first loads the list, loads the method (sort) followed by calling the method on the list without any arguments, whereas the the sorted_builtin function first loads the built-in sorted function, followed by loading the list and calling the loaded function with the list as argument.

Additionally, both use the same sorting algorithm: Timsort. So if both are using the same sorting algorithm and the bytecode of both is pretty much the same, why are the timing results different?

My guess is, that as list.sort can work with a known size, and swap elements within that size, whereas sorted has to work with an unknown size. Therefore, the new list created by sorted needs to be resized if not enough memory is left when appending a new element. And this takes time!

Having a look at the CPython source code, we find the following comment about resizing list objects:

The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, …
- CPython: Objects/listobject.c

If we bring back to mind, that we are dealing with a list of size 1.000.000, we can see: that’s a lot of resizing! Unfortunately, this is the best answer we get, when asking why list.sort is 13% faster than sorted .

Unfortunately my guess is wrong. As Nick Coghlan, one of the CPython core developer, stated on Twitter, the size of the resulting list is known. Basically, the following is happening:

new_array = arr.copy()
new_array.sort()

Nick Coghlan on Twitter

@anthonypjshaw @DahlitzF This theory is not correct - sorted knows how big the input is in this case, so it can preallocate the output. What it can't avoid is the extra data copying required to make a whole new list - if you measure "arr2 = arr.copy(); arr2.sort()" it should be comparable to sorted(arr).

However, he also states, that it’s not really obvious if you don’t know that it’s there and look explicitly for in the implementation.

Nick Coghlan on Twitter

@anthonypjshaw @DahlitzF The resizing idea was a decent guess though - even when you go read the source code, the preallocation trick is buried way down in the list.extend implementation, and hence is easy to miss if you don't already know it is there :)

This implementation results in the execution time difference as creating a copy of the list takes some time.

Additional Remarks

Before wrapping up this article, let’s have a look at what the official Python documentation says about this topic.

You can also use the list.sort() method. It modifies the list in-place (and returns None to avoid confusion). Usually it’s less convenient than sorted() - but if you don’t need the original list, it’s slightly more efficient.
 — Sorting HOW TO

As you can see, the official documentation states, what we have already proven: list.sort is slightly more efficient. Furthermore, it tells us, that sorted is usually more convenient.

Another question that my arise is, whether both sorting techniques are stable. Fortunately, the docs have an answer to that:

Sorts are guaranteed to be stable. That means that when multiple records have the same key, their original order is preserved.
 — Sorting HOW TO

This is also true, when using the reverse parameter or applying the reversed function twice.

Conclusion

The previous investigations showed us, that list.sort is slightly faster than sorted and consumes around 24% less memory. However, keep in mind that list.sort is only implemented for lists, whereas sorted accepts any iterable. Furthermore, if you use list.sort, you will lose your original list.

I hope this article revealed you more insights into the Python programming language. Stay curious and keep coding!

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

Run Python Applications as non-root user in Docker Containers — by example

After the emersion of the runC container runtime bug it’s finally the time to run processes in Docker containers as non-root user. This article shows you how to achieve that with your Python applications.

Using requirements.txt

If your project uses a plain requirements.txt , you can use the following snippet to run your application as non-root process in the Docker container.

pip is upgraded before using a worker user, because it’s installed as root and can’t be accessed by a non-root user. After switching the current user to the worker user every COPY instruction needs the --chown=<user>:<group> flag to signal to change the file or directory owner to the worker user (it’s root by default).

Running pip install with the --user flag installs the dependencies for the current user in the .local/bin directory in the users home directory. Therefore, we need to add this newly created directory to the PATH environment variable.

Using Pipenv

As many projects use Pipenv to handle their dependencies, here’s a way to run your Python applications, which depend on Pipenv, as non-root process in a Docker container.

This one is very similar to the previous one. Notice that the .local/bin directory is added to the PATH environment variable right after Pipenv is installed. As Pipenv itself is installed with the --user flag, it’s installed inside the .local/bin directory. To make use of it in line 14, it has to be added to PATH .

Conclusion

I hope this short article helps you running your Python applications safely as non-root user in a Docker container. If there are any questions, feel free to leave a comment or contact me via Twitter. Make sure to share it with your friends if you think it’s a helpful article. Thanks for reading, stay curious and keep coding!

Recently, I wanted to start my open source journey by contributing to an open source project called wily. The issue I was working on was to first add a version flag to print the current version of the tool and second to add the version to the help page.

As the project uses click to create a user friendly command-line interface, the help page is auto-generated based on the docstrings. That’s great, but refuses to inject custom dynamic texts. To recall the example of adding the version to the help page, you need to update your version twice: Inside of the __init__.py and inside of the docstring of the main cli command. But you don’t want to change the version of the tool at two places. So, how can you dynamically inject it into the docstring?

A quick research about functions docstrings reveals, that you can access and modify them using function_name.__doc__ . Problem: You can’t do it inside of the function itself as the docstring is added after function creation. Solution: Modify the docstring afterwards. And to anticipate decorators are great for that!

So, let’s demonstrate that by an example project. Consider the following project structure:

└── tool
    ├── __init__.py
    ├── __main__.py
    └── custom_decorators.py

tool is our tools directory, the __main__.py will include the logic of the command-line tool and custom_decorators.py contains our decorator, which we will use later to change the help page.

Let’s start by having a look at the __init__.py:

As you can see, it only contains the __version__ of the tool. Next, we will have a look at the __main__.py:

It’s just a very basic command-line tool created with click. If you are not very familiar with the code, check out the documentation. You are able to print the version using tool --version and print some text using the do command:

$ python tool/__main__.py do "Some Text"

As already mentioned, you are able to display the help page using --help natively, which is generated based on the docstrings. Let’s modify the help page a little bit! Therefore, we will add the tools version to the help pages heading.

First of all, we need a custom decorator modifying the __doc__ attribute of the cli function, which is our main method or group in this case. Let’s call the decorator add_version and put the corresponding code into tool/custom_decorators.py. The code is pretty straightforward:

Now, we only need to add the decorator to our cli function before all other click decorators are applied:

That’s it! We changed the auto-generated help page and injected the tools version using a custom decorator. The whole project can be found on GitHub. Feel free to get it running on your own machine, to extend it further and to share it!

If you liked it, clap for the story. Feel free to leave comments and share it with others. Thanks for reading, stay curious and keep coding!

A few months ago I’ve seen a tweet from a Python learner with a code snippet containing f-strings. I asked, why she’s not using format() . She answered, that this is the new way of formatting strings. I was curious about it as I didn’t hear about it before. Seeing other people using it, I started to do it as well.

Two weeks ago I spotted a Pull Request on GitHub where somebody used f-strings to convert a value to a string as in the example below.

I was surprised by the usage of f-strings in this particular case. Another user commented to use str() instead. This conversation led me to the question, which one of both is faster as it was a computationally intensive piece of code.

Using boxx.timeit showed me the not irrelevant time difference.

“f-strings” spend time: 0.08900404
"str” spend time: 0.160588

Wondering why this is the case? Looking at the byte code gives us the answer. Python provides a module for such cases, the Disassemble-Module. Let’s have a closer look at what’s happening.

The result is shown below.

As you can see the str_string method consists of one more command (CALL_FUNCTION). Function calls are expensive and f-strings don’t need to call a separate function.

To summarize f-strings are faster than str() in terms of converting integers and such types to string. But keep in mind, that we only had a look at simple types. How they perform on more complex types is currently out of my knowledge as I didn’t test it.

Feel free to leave a comment with your own thoughts. Stay curious and keep coding!

Ending up the #100DaysOfCode-challenge with informing about newer Python releases, asynchronous programming and community work.

With this article I not only summarise my past two weeks of learning and coding, but also end up my #100DaysOfCode-challenge. Two weeks ago I had ten days left before finishing the challenge and decided to spread them over two weeks to have some more time to get into Python a little deeper.

More insights into Python

The past two weeks I spent more on getting deeper into Python itself than working on a specific project like my personal portfolio page. Therefore, I read different PEPs at the official Python page as well as followed the Python Model Of The Week (PyMOTW). I tested the sched-package providing great resources for schedulers, and the linecache-package. Additionally, I traversed GitHub searching for interesting Python projects to contribute to.

At some point I helped a fellow student refactoring his own codebase and applying PEP 8 to it, so that he has it easier to contribute to others projects in the future or that others can contribute to his projects easier.

Besides the previous mentioned things I also spent time on getting my portfolio page done. Unfortunately, I’m not finished yet — still struggling with getting the first things running on an Ubuntu server. This will be the project I will focus on in the next weeks.

Furthermore, I kept reading Python Tricks from Dan Bader, which made me become a more pythonic coder. I can really recommend this book to everybody, who’s interested in Python!

Additionally, I made some more community work than before helping others to find a solution for their problems. Therefore, I read issues at GitHub projects I worked with and provided my own solutions if necessary.

Last but not least I worked with asynchronous-package like asyncio and tornado. The whole topic asynchronous programming is really powerful and interesting, so I will keep an eye on that.

After all I have to admit, that the past challenge was sometimes very easy and sometime really challenging. It was a great experience to finish the second round of it and I can only recommend to everybody to do it on it’s own.

I won’t update this blog weekly as I did during the challenge, but I will post updates once in a while and maybe some more articles on “How to …” do something.

Thanks for the great support during the challenge and for reading this, stay curious and keep coding!

Articles and Podcast Episodes

Providing a list of great articles I’ve read over the past week and podcast episodes I’ve listened to got a natural part of my weeklies summary. Here are the lists for the past two weeks.

Articles

• Asynchronous Python — Await the Future
• What’s New In Python 3.6 (with the focus on PEP 530)

Podcast Episodes

• The importance of transparency and user control in machine learning — O’Reilly Data Show
• #158 Quantum Computing and Python — Talk Python To Me
• #74 Contributing to Open Source effectively — Python Bytes
• How language shapes the way we think | Lera Boroditsky— TED Talks Daily

#16 and #17 Week of the Year was originally published in Coding experiences on Medium, where people are continuing the conversation by highlighting and responding to this story.

A week on the subject of image recognition and Python secrets everybody should know about.

Image and Video Recognition

This week I started with the focus on learning more about image recognition with a predefined model instead of a neural network. I already worked with OpenCV manipulating existing images and created a package for colour manipulation.

To keep things simple I searched for a predefined model, which would detect faces in an image if implemented correctly. I found a useful set of cascade classifiers and imported the one for face recognition. After that I made use of OpenCV’s multi-scale detection method detectMultiScale() to find all matching objects in a given image. Furthermore, I unpacked the results and drew red rectangles around the found coordinates marking the faces. One of the test results is shown in the thumbnail.

So far so good. But what about recognising faces and objects in videos? This seemed more powerful and interesting to me, so I started to find out, how to launch the webcam of my laptop, make a short video and to the same thing with every collected image as in the example before.

Luckily, OpenCV provides build-in functionalities for that as well. Turning one the webcam and collecting images as long as the user wants was very quite easy. Now the more difficult part impended: Recognising single objects in a series of images.

To solve the problem I set the first made image as my basic background frame. Every image collected afterwards was compared to the first one. This was done by simply calculating the difference between each frame. The result of the subtraction was a new frame. Applying certain thresholds to it created a black-white frame with new appearing objects in white and everything else in black. With the received coordinates of the new appearing objects I was able to draw a red rectangle around them and hence to mark moving objects.

The motion detection application is not perfect right now due to mis-detection of certain objects and under changing light conditions. But it was a great first try on this topic.

Python’s ABC-package

However, I did not only worked on image and video recognition, though. I made a quick excursion into Python’s object-oriented fields. Doing so, I came across the Abstract Base Class-package (ABC) providing great decorators for ensuring correct class implementations and inheritance.

Because code speaks more than words, I show you the beauty of the ABC-package in three pictures:

The above picture shows you, that with the correct implementation of ABC you are not able to run an application if an important method (in this case bar()) is missing.

This picture illustrates, that it’s not possible to instantiate the base class, which is quite helpful in many cases. In many applications and frameworks base classes shouldn’t be instantiated. Only concrete classes inheriting from the base class.

The last picture shows a working implementation with a base class and an instantiation of the concrete class.

Additionally, I learned about shallow and deep copies of objects and how to create them using Python’s copy-package. You should definitely check it out.

Additional Information

Besides the mentioned topics, I kept working on my personal portfolio page, listened to several podcast episodes and learned about Python’s __str__() and __repr__() dunder methods.

Summarising the past week I have to admit, that it was only another “light” week of coding. University stuff keeps me busy, but nevertheless I try to code everyday until the end of the #100DaysOfCode-challenge. Staying curious and keeping coding as always is a passion, that needs to be lived!

Articles and Podcast Episodes

As usual I share podcast episodes I listened to and articles I read over the past week and which are worth sharing.

Articles

• Pythonista 3 - A Full Python IDE for iOS
• Ten-lines-or-less — Python scripts that are short but useful or interesting
• How To Get Life-Changing Clarity Within 90 Minutes Of Waking Up

Episodes

• 39: Thorough software testing for critical features — Test and Code
• 37: What tests to write first — Test and Code
• This podcast comes in any color you want, as long as it’s black — Python Bytes
• 292: Elasticsearch and doubling down on “open” with Philipp Krenn — The Changelog

#15 Week of the Year was originally published in Coding experiences on Medium, where people are continuing the conversation by highlighting and responding to this story.

Playing around with IPython. Working on the command line. Going on finishing my portfolio page.

This week was the first week I was back studying in Mannheim. After two months of internship it was quite challenging to find back into routine. That’s actually the major reason, why I wasn’t able to code as much as I usually do and as I wanted to. Nevertheless, I coded around most of the days and provide a summary of the challenges I had to deal with and the insights I’ve got.

Playing around with IPython

For one year now, I do most of the things via the command line, because it’s in my opinion more powerful and — with a little training — faster as well. However, I stayed away from Vim for quite a long time. I only used it, when I wanted to change only one line of code and didn’t want to start a text editor for it. Back at university my professor for object-oriented programming asked us, what IDEs we used in the past. Because in his opinion nobody is working with Vim and the command line only. I told him, that I often use the command line and also Vim for minor edits. Due to the resulting discussion I decided to give it a try and worked the whole lecture only with the command line and Vim. Back home I didn’t stop doing it. Every Python code snippet I’ve made I used Vim for.

Currently, I’m reading Python Tricks from Dan Bader and he is making use of IPython a lot. I already was on the command line, so why not using IPython instead of Vim? Most of the things I was doing were for testing and learning purposes only, so no need to save them to a file. Best conditions for using IPython.

In my sessions I had a closer look at Python’s datetime and time packages. I created a small command line countdown, I nice gimmick for a boring lecture! Have a look at the far easy application:

You can specify the time of the end of the countdown via the command line argument -t.

In the lecture we also had to deal with Java. And guess what? Compiled and ran it via the command line…

Python Tricks

Over the past week I dived deeper into Dan Bader’s book Python Tricks, which I can recommend to everybody going further using Python. I learned about the use of assert and Python’s lambda-functions.

Furthermore, I was guided through the creation and usage of closures and decorators. I created several decorators on my own. The most useful is in my opinion the trace decorator, which logs function calls for you:

import functools

def trace(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        print("-" * 20)
        print(f"TRACE: calling {func.__name__}() "
              f"with {args}, {kwargs}")

        original_result = func(*args, **kwargs)

        print(f"TRACE: {func.__name__}() "
              f"returned {original_result!r}")
        print("-" * 20)

        return original_result

    return wrapper

Note, that the @functools.wraps() is used to protect the loss of meta data. Possible docstring will be available after wrapping the function. The *args and **kwargs ensure, that using arguments is still possible.

Additional Stuff

It’s worth to mentioned, that I found PyMOWT (Python Model Of The Week) maintained by Doug Hellmann. This site uncovers one Python model of the standard library every week providing great examples of how to use it and explanations about the existence of it. It’s a very powerful resource to look up certain packages you heard of.

That’s it. Not so many things to write about as usual, but better than nothing! Wish you a week of great experiences, stay curious and keep coding!

Articles and Podcast episodes

As always I provide a list of articles I’ve read and episodes I’ve listened to and that are worth sharing.

Articles

I read only a few articles about programming this week and none of them are worth sharing. First time this section will be left empty.

Episodes

• #71 We can migrate to Python 3, careful please — Python Bytes
• #72 New versioning: Episode 0.0.7.2 (with 72 releases) — Python Bytes
• CR244 Das Ende von Facebook? — Chaosradio
• #157 The Journal of Open Source Software — Talk Python To Me
• How we can teach computers to make sense of our emotions | Raphael Arar — TED Talks Daily

#14 Week of the Year was originally published in Coding experiences on Medium, where people are continuing the conversation by highlighting and responding to this story.