I recently started reading the pym book suggested by folks at #dgplug. Since I have been programming in Python since an year and a half, I could go through the basics fairly quick. Here are the topics I covered:

  • Variable and Datatypes
  • Operators
  • Conditionals
  • Loops
  • Python Datastructures
  • Strings
  • Functions

However, file handling is something I have rarely used till now. This blog talks about the it and some of the great takeaways.

Opening a file

A file can be opened in three modes: ### Read: Opens the file in read-only mode. The file cannot be edited or added content to. The syntax for the same is :

>>> f = open('requirements.txt' , 'r')

### Write: Opens the file in write, you can make desired changes to the file. The syntax for the same is:

>>> f = open('requirements.txt' , 'r')

### Append: Opens file in append mode. You can append further content, but cannot change or modify past content. The syntax for the same is:

>>> f = open('requirements.txt' , 'a')

Reading a file

When a file is openened in read mode, the file pointer is at the beginning of the file. There are different functions for reading the file:


It reads the entire file at once. The file pointer traverses the entire file on calling this function. Therefore, calling this function again will have no effect, since the file pointer is already at EOF. Syntax for the same is:

'selenium >= 3.141.0\npython-telegram-bot >= 11.1.0\ndatetime >= 4.3\nargparse >= 1.4.0\nwebdriver-manager >= 1.7\nplaysound >= 1.2.2'


This function moves the file pointer to the beginning of the next line hence outputting one line at a time. Syntax for readline() function is :

>>> f.readline()
'selenium >= 3.141.0\n'
>>> f.readline()
'python-telegram-bot >= 11.1.0\n'


Reads all the lines in a file and returens a list.

>>> f.readlines()
['selenium >= 3.141.0\n', 'python-telegram-bot >= 11.1.0\n', 'datetime >= 4.3\n', 'argparse >= 1.4.0\n', 'webdriver-manager >= 1.7\n', 'playsound >= 1.2.2']

Now, we should always close a file we opened when not in use. Not closing it increases memory usage and degrades the quality of code. Python offers nice functionality to take care of file closing by itself:

with keyword

`with keyword can be used as follows:

>>> with open('requirements.txt' , 'r') as f:
'selenium >= 3.141.0\npython-telegram-bot >= 11.1.0\ndatetime >= 4.3\nargparse >= 1.4.0\nwebdriver-manager >= 1.7\nplaysound >= 1.2.2'

Writing into a file

The .write() function can be easily used to write into a file. This will place the file pointer to the beginning and over-write the file completely. Here's how that works:

>>> f = open('requirements.txt' , 'w')
>>> f.write('tgbot\n')

The return value '6' denotes the number of characters written into the file

Hope you enjoyed reading the blog, :)

Contributing to open source is one of the best ways to hone up programming skills. Along with writing quality code, using a version control tool plays a crucial role while contributing. There are a lot of source control management platforms such as github , gitlab , phabricator etc. This blog discusses about making code contributions via github.

So what Is a Pull Request?

Pull request, as the name suggests is a patch of code that is sent to original code base to be merged into the source code after review. Usually, maintainers of the project will review the PR(pull request) and merge it into original code base if everything looks okay.

How to make a PR?

1. Fork the Repository and clone

First off, there should be a fork of the upstream repository. Fork is nothing but a copy of the upstream repository onto your own github. This is where you will be pushing your changes. (Since you own it :D) Then, clone of repository so as to do the changes locally and testing them before sending a patch. This should be fairly simple using git clone <repository URL>

2. Make a new branch

Now, if we want to make a change to the source code, we should always ensure that the master/development branch to be always in sync with upstream. You would definitely not like messing the master branch , and if in case the issue's priority is not high, the PR will be pending with the changes in master branch.

Other than that, the master branch is 'supposed' to have the updated code(or the production code), the rest of the features are supposed to be done on separate branches before being pushed into production.

Thus, it it is always a good practice to make new branches for each pull request to be opened. To do this use git checkout -b <branch_name> -t upstream/master This will make the branch in sync with the upstream. If upstream is not added, you can manually add it to remote using git remote add upstream <upstream_URL>

Or alternatively, you can just create a branch and fetch from upstream using:

   git checkout -b <branch_name>
   git fetch upstream

3. Make changes in the created branch and push

make the required changes and commit them via git add and git commit commands After the changes are done, push to your code via git push origin <branch_name>

4. Make a pull request

Usually, just after pushing to github, you would button when you open your repository(on github) clicking on which a PR will be made. It should look something as follows:

PR image

If that doesn't show automatically, navigate to the branch(on github) and make a PR.

That is it! Now keeps doing the requested changes(if asked) locally and keep pushing code on the created branch till the point it is fit for merging.

I have been using git from quite some time, but there are certain amazing things about git that I learnt just recently.

1. Blaming with git blame

git blame gives the commit hash, author and time for every line in a file. This can be used to know who are the people who have contributed to that particular code and the commit hash too! It can also help figure out who added a particular line in a project which broke it, and then go blame them :P

2. Rectifying via git commit —amend

Ever been in a hurry and made a spelling mistake? That's exactly what is command is for! This can change the commit message for the last commit. Just type git commit --amend that would open the file in the default terminal text editor. Change the message, save and quit, and done!

3. Squashing

Squash is not a command, but definitely a concept in itself. Imagine having changes in a file multiple times, which would make a lot of unnecessary commits. Now if any point of time, one needs to go back in history, doing that would be just plain painful with several commits cluttered. Squashing here comes to rescue! Squashing means convert related commits to one commit. It's nothing but a kind of interactive rebase. for last n commits you can do git rebase -i HEAD~n. Here's how it goes: squash1

This will open the commits in the default text editor. Instead of pick in front of commit, type squash for those commits you wish to squash.


Save and exit, you will get another file which asks the user to choose final commit messages. Type the appropriate message and delete other messages. Save an quit, it's squashed! \o/

4. Stashing

While working on projects, things are in a messy state and you want to switch branches for a bit to work on something else. Now, you do not want to commit things half done(you need to commit everything before switching). git stash comes to rescue! Stashing takes the current state of your working directory and pushes it onto a stack of unfinished changes. Now you can switch branches! You can also apply the unfinished changes any time with git stash apply

5. Tagging

Tagging is a feature in git. For every software there are releases, now imagine if a software is released and development team is working for the next release. Meanwhile, there is a bug report with severe priority. Now, hat needs to be fixed in the previous version! Remembering the last commit for each release is not a good idea. Git here offers the functionality! It has the ability to tag specific points in a repository’s history as being important(releases). There are five basic commands:

  • git tag – will list all the tags in the project.
  • git checkout <tag_version> – jumps to the repository's state with the particular tag version.
  • git tag -a <version> -m '<commit message> – creates a tag with the version number and commit message.
  • git tag -d <tag_name> – deletes the tag from the list
  • 'git push origin —tags` – pushes tags to the origin

6. Applying patches

A lot of open source work is done via mailing list. The kernel mailing list comes at the top of my head. A lot of commits are mailed as patches. These patches contain the diffs(git diff). They can be easily applied via git apply <filename>. Now the code can be tested with the patch applied.

7. Short git status

Git has a short status flag so you can see your changes in a more compact way. If you run git status -s or git status –short you get a more simplified output from the command. status-short The ?? indicates the file hasn't been staged. D indicates deleted file and there are a few other tags too.

8. Cloning can be done under a different name

You don't need to have a weird name that the upstream would have to your repository. You can always rename the directory while cloning. The syntax is: git clone <upstream URL> <directory name>

Git is indeed a wonderful tool in itself. There's so much to learn. Hope you enjoyed reading the blog, :)

Ever wondered to get a GUI application from another machine get rendered onto yours? If not, Linux offers that to you :P Let's see how: First of all we shall discus some basic terminologies before moving ahead:

The display server

The display server is very similar to a web-server. So Imagine that you have an apache server. Now when a client requests a service, the server would send a few instructions accordingly to the client over http/https protocol. The client(which here is the web browser) will render those instructions and display the content requested. The display server in Linux works almost the same way. The server here interacts with the hardware (CPU) and sends instructions over a protocol known as the 'X' protocol. The latest version of the same is 11, and hence it's called X11.


Think what would happen if the display-server is on one machine and client on the other machine? Yes! that would render the graphical applications onto the client machine. That's is exactly what X-forwarding is – render the application on one machine while it runs on a different machine.

Okay, enough of terminologies, let's get to implementing it now.

On the server, configure /etc/ssh/sshd_config to contain the following:

X11Forwarding yes
X11DisplayOffset 10

These two are usually commented out, ensure that the sshd_config contains these. You may need to restart ssh for the changes to be picked up. You can run this if the ssh server doesn't pick that up and then restart the server:

cat /var/run/ | xargs kill -1

Next, start ssh on both the machines. On Debian or Debian derivatives you can do so by doing:

sudo service ssh start

Now we will connect the client to the server. On the client machine type:

ssh -X <server name>@<server ip>

If you are facing trouble finding out ip, you can do so via:

nmcli -p device show

And it's done! You have SSH'd into the server machine. Now you can render GUI apps on the client machine, while it runs on the server.


Here's me rendering firefox on the client :D

I recently started interacting on #dgplug channel using my matrix ID and I’m also attending the dgplug summer training, in-turn learning a lot of new stuff. As all of us(dgplug summer trainees) were learning about mailing list etiquette and FOSS, we were suggested by mbuf (Shakthi Kannan) to go ahead and read his book ‘i want 2 do project. tell me wat 2 do.’ to get better insights for FOSS, mailing etiquette, how FOSS works etc.

The book then showed up at my door after a couple of days. This book presents valuable insights on open-source software and the equally important communication side related to it, which a newbie wouldn’t pay much attention to in the beginning.

The book starts with Mailing list etiquette and explains it in detail – it explains the importance of trimmed, ‘interleaved, bottom-posting’, not writing HTML mails, no overquoting , really well. It also made me realize how important adding additional details are. When I delved in further, I learnt about the tools that can be used for effective communication(mailing lists, IRC, SMS, Voice Calls) and when to use the right tool, with right people at the right time.

Next up, I learnt about the details for starting in open-source software development, how to effectively read docs to proceed with the code-base. Then, in chapter-5, the whole process of creating a patch and e-mailing it is explained. A few days back I too had to merge a mailed patch to my repository so I could very well relate to the process of generating a patch via Version Control System(VCS) Tool and submit the patch via mail.

As I read further, I came across one of the most important take away from the book – Bug Triaging. It’s nothing but, reproducing the same bug from the mail/description and work upon it. It thus, also means that the mail/description should contain as much detail as possible for the debugging to be smooth.

The last three chapters focus on reading /writing, presentation and sustenance and have nice pointers to follow. The chapter-9 on presentation made me look back at the mistakes that I made while delivering talks at past meetups. I took a note of all the points that I missed so that I can deliver my next talk as perfectly as I can, 🙂

That’s about it. Thank you Shakthi Kannan , for this amazing book! Here's my photo with the book: