DEV Community: vybhav72954

Let's talk about Sys

vybhav72954 — Mon, 24 May 2021 12:45:41 +0000

Everybody loves Python (Trust me, everybody does). But why? An intuitive, simple, yet highly scalable language, Python is a dynamically typed, interpreted language. However, we will not dive into the nitty-gritty of Python's properties but will instead focus on the functionality of the interpreter of Python.

sys module in Python provides information about constants, functions, and methods of the Python interpreter. Moreover, it also provides access to multiple variables under the command of the interpreter and their associated methods. So basically sys module allows one to operate over the interpreter, so what, is it useful?

Let's talk about some interesting use cases of sys module.

Installation

But first of all, how to access the sys module?

sys is part of Python 3.x Standard Library, so no separate installation is required.

Just import it and you are good to go.

To verify sys, let's start by checking its version.

# Imports
import sys

print(sys.version)

3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:57:54) [MSC v.1924 64 bit (AMD64)]

Viola! It's working. For more information about sys and its license, run sys.copyright.

Basic Usage

Let's start with some basic use cases of sys module.

sys.maxsize returns the max value that an int variable can hold.

import sys

print(sys.maxsize)

9223372036854775807

sys.path returns a list containing all the paths to all the Python Modules and the interpreter in the running environment.

import sys

print(sys.path)

['C:\\Users\\asus\\PycharmProjects\\Auto_Caption_Generator', 'C:\\Users\\asus\\PycharmProjects\\Auto_Caption_Generator', 'C:\\Program Files\\JetBrains\\PyCharm 2020.3.3\\plugins\\python\\helpers\\pycharm_display', 'C:\\Users\\asus\\AppData\\Local\\Programs\\Python\\Python38\\python38.zip', 'C:\\Users\\asus\\AppData\\Local\\Programs\\Python\\Python38\\DLLs', 'C:\\Users\\asus\\AppData\\Local\\Programs\\Python\\Python38\\lib', 'C:\\Users\\asus\\AppData\\Local\\Programs\\Python\\Python38', 'C:\\Users\\asus\\Music_Classification']

sys.platform can be used to identify the running platform (operating system).

import sys

print(sys.platform)

win32

sys.executable tells where the Python interpreter is present.

import sys

print(sys.executable)

C:\Users\asus\Music_Classification\Scripts\python.exe

sys.modules returns a dictionary containing names of all modules in the current environemnt.

import sys

print(sys.modules)

{'sys': <module 'sys' (built-in)>, 'builtins': <module 'builtins' (built-in)>, '_frozen_importlib': <module 'importlib._bootstrap' (frozen)>, '_imp': <module '_imp' (built-in)>, '_warnings': <module '_warnings' (built-in)>, '_frozen_importlib_external': <module 'importlib._bootstrap_external' (frozen)>, '_io': <module 'io' (built-in)>, 'marshal': <module 'marshal' (built-in)>, 'nt': <module 'nt' (built-in)>, '_thread': <module '_thread' (built-in)>, '_weakref': <module '_weakref' (built-in)>, 'winreg': <module 'winreg' (built-in)>, 'time': <module 'time' (built-in)>, 'zipimport': <module 'zipimport' (frozen)>, '_codecs': <module '_codecs' (built-in)>, 'codecs': <module 'codecs' from 'C:\\Users\\asus\\AppData\\Local\\Programs\\Python\\Python38\\lib\\codecs.py'>, 'encodings.aliases': <module 'encodings.aliases' from 'C:\\Users\\asus\\AppData\\Local\\Programs\\Python\\Python38\\lib\\encodings\\aliases.py'}

sys.exit can be used to terminate a program at once.
Apart from these CLI usages, sys can be used for I/O as well:
- stdin (Get input from the command line)
- stdout (Display output on the screen, the beloved print is just a wrapper around stdout object)
- stderr (The source of all the error messages, each and every exception is handled and written to stderr)

Advanced Usecase

These are some simple usage of sys module. Let's take one advanced use case:

I made a script to determine the traffic on all of my GitHub Repositories. I was having a look at the Pickled database and was unable to determine the corresponding Repo. I knew that my script took the name of GitHub Repo as an argument. By using sys.argv in the driver code. I was able to determine the exact arguments provided to the script.

if __name__ == "__main__":
    main()
    print("Arguments: ", str(sys.argv))

2021-05-13T00:00:00Z {"uniques": 1, "count": 4}
2021-05-20T00:00:00Z {"uniques": 1, "count": 2}

2 elements
Arguments:  ['github_traffic.py', 'view', '-u', 'vybhav72954', '-r', 'My_Junk']

Granted, there are more straightforward ways to sort this problem, but using sys.argv can be really helpful when writing scripts containing multiple classes and functions.

In Closing

Sys is another helpful module in Python Standard Lib, which has multiple basic to advanced use cases, with standard I/O being the most practical application, sys can be used in other scenarios as well, which are discussed above.

There is much more to sys but was out of scope for this blog like managing hooks, recursion depth, traces, encoding, and profiles. There are other useful methods as well; for a detailed insight, have a look here.

Beginners Guide to Auto Formatting

vybhav72954 — Sun, 28 Mar 2021 17:41:56 +0000

Everybody loves Python! (mostly). But why? I asked many programmers across my network (Trust me, I did!). And the most pronounced response was its high readability, simple syntax, and similar Pythonic traits. Indeed, a high level of readability was on the top of the mind of Guido van Rossum as he developed Python.

Let’s take a small example. The staple of all programs, the infamous “Hello World!” program in Java, looks like this:

class HelloWorld {
    public static void main(String[] args) {
        System.out.println(“Hello, World!”); 
    }
}

While in Python, it looks like this:

print(‘Hello, world!’)

Looks simple right? Even better examples, like opening and appending files in Python, are comparatively more straightforward and less taxing than other languages.

But before proceeding, let’s make a few things clear.

There are languages with even simpler syntax and learning curves, Lisp and Smalltalk are great examples. Even Ruby on Rails can fit the constraints.
Even though it is simple, Python is not THE best programming language; there is NO best programming language. There are languages which you know, you love it and sharpen your skills using them, and there are languages which you don’t know and might learn someday own the line. (PHP is an exception, you never want to practice PHP).
There are beginner-friendly languages, Python is one of them, but I don’t think it’s a good description.

Programming languages are situational, to say the least; it depends upon what you want to achieve, how you want to achieve, and when you want to achieve.

Python Styling Guidelines

Now with that out of the way, let’s talk about why Python is so great 😛. So, like previously mentioned, is it the easy syntax? Higher flexibility? Or something else? Well actually the big picture is a little bit different. Python was developed with a high level of readability in mind, it’s the idea that code is read much more often than it is written, and this is where everything glues together.

Python is good because it is easier to read and comprehended, sure it means that writing is more accessible. But writing is not the idea behind Python, it’s reading the code. The easier syntax does make it easier to write the programs, but the true purpose they serve is to the readers and reviewers, other benefits are just cherry on top. For that very reason, Pythonistas follow a set of guidelines, a.k.a. “Pythonic” idioms. But why am I talking about this? It is evident that Python is flexible and easy to read/write; a lot of people are attracted to writing programs in Python, but what they forget is the styling part of Python, and hence the result is a poorly formatted code, which don’t get me wrong, still works fine but isn’t what Python is actually meant for. This tweet summarizes the Styling part really well.

PEP-8

In a nutshell, we have some not-so-strict styling guidelines for Python. Ummm NO. Actually, the procedures are very strict, adequately formatted, and universally accepted; just the problem is that beginners don’t abide by them, and with time it becomes habitual.

PEP-8 is the de facto code style guide for Python. It should be strictly followed and mandatory in top projects such as “Flask”, “Tensorflow” etc.

A well-documented version of the guidelines can be found here. The Hitchhiker’s Guide to Python is my go-to version of guidelines for properly formatted code.

If you are a beginner and want a simpler take on PEP-8 guidelines, I have prepared my own version of Python guidelines used in an open-source project, Rotten-Scripts. This is way more beginner-friendly but also aligns with the mandatory guidelines of PEP-8.

Auto Formatting

Now let’s address the elephant in the room; Have you just started coding in Python, and these guidelines seem way too much? Are you a seasoned pro, but PEP-8 guidelines still overwhelm you at times? There is a simple solution for all this, Auto Formatting. Before getting into Auto Formatting, it should be clear that the tools mentioned below can just act as an aid, and one should try to learn the guidelines, and one should be able to write good quality code without using any tool.

Several auto-formatting tools can reformat your code to comply with PEP-8.
We will discuss 3 of my favorites.

But before discussing auto-formatting, one question pops up in mind; What if my script is already looking good and everything is working correctly? For example, take this python script,

It looks horrible but is working correctly, now I know that this is a rather extreme example, but it serves the purpose here. Before anything, we need to determine what are the discrepancies in our code. For this, we will use pycodestyle, previously known as pep8.

pip install pycodestyle
pycodestyle test.py

Output:

test.py:1:12: E401 multiple imports on one line
test.py:1:17: E703 statement ends with a semicolon
test.py:3:1: E302 expected 2 blank lines, found 1
test.py:4:5: E265 block comment should start with '# '
test.py:4:80: E501 line too long (135 > 79 characters)
test.py:5:15: E225 missing whitespace around operator
test.py:5:17: E201 whitespace after '('
test.py:5:21: E231 missing whitespace after ','
test.py:5:26: E231 missing whitespace after ','
test.py:5:31: E202 whitespace before ')'
test.py:5:33: E703 statement ends with a semicolon
test.py:6:18: E225 missing whitespace around operator
'
'
'

As expected there are a lot of problems here, this code is nothing short of a nightmare for a debugger and/or reviewer. Now we can start playing around using the autoformatting tools mentioned above. I won’t be discussing the detailed workings of these tools, as they have proper documentation, multiple options, and configurations for helping you out. Instead, we will be focusing on some hands-on implementation of the formating tools to provide a good starting ground.

So, let’s start by downloading the required packages. I personally prefer to make separate virtual environments for these tools, validate a copy of my scripts in that virtual environment, and simply do the changes in the original scripts. You can do the same by setting up a virtual environment and run the following commands. I am planning to make a cheat sheet for this soon as well, stay tuned.

pip install yapf black autopep8

After downloading all the required packages, let’s use all the formatting tools one by one and see how they can help us. All the tools follow similar steps and provide matching options but can still offer different results. Just ensure that you are in the directory in which your scripts are.

Autopep8

Autopep8, Just like its name, it automatically formats Python code to conform to the PEP-8 style guide. A simple hands-on approach autopep8 is widely regarded for its flexibility and customization. To correct your file, use the following command.

autopep8 -i -v test.py

-i or --in-place flag make changes to files in place, and -v or --verbose is for verbose messages.

Output:

Look at that, way better! But wait, there is more. The good thing about autopep8 is, it allows aggressive changes as well. By using -a or --aggressive flag, autopep8 aggressively formats the code, enabling non-whitespace changes. Let's see this in action, shall we?

autopep8 -i -v -a test.py

Output:

Clearly so much has changed, this shows how flexible auotpep8 actually is, but there is even more.

By stacking multiple -a,

autopep8 -i -v -a -a -a test.py

even more aggressive changes can be forced. After using the aggressive flag multiple times, this is what the file looks like.

Output:

3 level of aggressive changes in my opinion is a bit of overkill and solves most of the purposes.

YAPF

YAPF is a project by Google is a rather advanced auto-formatting tool and can even beautify code that follows PEP-8 guidelines to make it look even better. The approach is similar to clang and gofmt, in order to auto-format a file, use the following command:

yapf -i -vv test.py

-i or --in-place flag make changes to files in place, and -vv or --verbose is for verbose messages.

yapf allows you to format the code according to Google and Facebook guidelines as well; by using style google or style facebook scripts can be reformatted according to the prescribed styling guidelines.

yapf -i -vv test.py style google

Black

Black is the most-loved and/or most-hated formatter (depends on how you look at it), a truly uncompromising formatter, refactoring the code to its minute details, black results in a faster, more optimized code. Its uncompromising nature can result in scripts utterly different from the original ones and is many a time considered an overfill. In order to use black, use the command:

black test.py

Notice the shift from single to double quote, extra blank lines, etc. Black incorporates multiple changes that can completely change the way a script looks like.

Coming back to my early statement, Black is the most-loved and/or most-hated formatter, how? Black provides nearly No, and by that, I mean no customization; it is truly uncompromising. There are definitely things that can be changed, but the fact that Black is a simple nonconfigurable tool still holds true. A common argument is that the "best tools do not need any configurations"; this might hold true for gofmt (a similar auto-formatting tool for Go) but Python is not Go. A lot of people still love using Black. “Black is opinionated, so you don’t need to be.” sum everything up pretty well.

Other tools like autopep8 and yapf provide much more configurations and customizations, but that part is out of this article’s scope.

Why no Auto Formatter?

There are reasons why you should not use Auto-Formatter, like the unnecessary clutter that Black introduces in the output of git blame, but since the newer versions of git, these problems have been solved, and tools support ignoring revisions, so its no longer an issue.

My Final Take

Black, yapf, and autopep8 are some great tools, but personally, autopep8 is my go-to auto formatter with a flake8 linter (What is a linter? Wait for my next blog, maybe :P) and Travis for test cases and continuous integration.

Bottom-line:

Auto format tools like yapf, autopep8 and black are just options, not solutions. Ultimately you should strive to learn the guidelines yourself as they are the heart and soul of Python. In case you are contributing to open-source projects, tools like these help a lot. Every maintainer loves good clean code. Always remember, it is not enough for code to work if you want, So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

Like I said earlier, I am planning to make a cheat sheet for this soon as well, stay tuned.

Liked what you read? I have restarted blogging after a long time; I talk about multiple stuff (Football, Anime, IoT, Music, Human Emotions, to name a few). You can follow me on my socials if you want.

Let connect; I love to get in touch with people who have a similar mindset, my LinkedIn.
For exclusive Tech Posts, check my Dev Profile.
Go through my GitHub, you might find something interesting.

Vybhav Chaturvedi, Over and Out.

First steps in GirlScript Summer of Code'21

vybhav72954 — Fri, 12 Mar 2021 09:50:12 +0000

2020 was crazy, from UFO videos to missing stars, a possible World War in the first week (Trolls) to a Worldwide pandemic, 2020 told everyone to hold its beer. And subsequently, we had the Worldwide Lockdown, no Colleges (Yippee), Work from Home (Sign me up for that), no Football (Well, that's bad), no Adventures, Trips, Movies, get together (Why 2020, why?) but still I enjoyed it a lot, cause during the early Lockdown I decided to get back into Open Source after a break of nearly two years. It was my first ever 2-month long Hackathon, and I was going crazy. I enjoyed working on a fantastic project under a smart and experienced mentor, the Semester Long Projects SLoP 2020, organized by the Developers Club of Dhirubhai Ambani Institute of Information and Communication Technology, was a memorable experience, with a nail-biting finish I was eventually able to secure the first position. It was a fantastic event, and more than winning, I was more excited to make connections that are still strong. I worked and got to know many people whose names still keep popping up here and there. After that one event, I never looked back, participated in various events, hackathons, and competitions, performing well in some, and even underperformed at times. Open Source made Lockdown a whole lot memorable for me.

Recently GirlScript Summer of Code came along, a vastly popular event organized by a well-respected EdTech organization, The GirlScript foundation. It is a 3-month long event dedicated to Open Source and provides a well-rounded opportunity to beginners who are just taking their first step into Open Source along with the seasonal professionals who are looking to contribute to a well-structured project. Numerous internship opportunities, fantastic prizes, and acclamation are just the tip of the iceberg as GirlScript Summer of Code (usually called GSSoC) guarantees the participants with an expanded network and a rigorous 3-month program full of coding (wow), documentation (hell yeah) and debugging (oh no!). A big shoutout to Harsh Mishra for recommending GSSoC to me and helping me throughout the process as I applied for the Mentor role in GSSoC. After waiting for days full of anticipation, I finally received the e-mail; for the next three months, I was going to be a mentor in GSSoC'21.

But this post is not about my role as a mentor, nor it's about GSSoC as a competition; there are more suitable blogs than this about the event and personals with a better story. This blog is meant for those who are taking their first step in Open Source via GSSoC; I will try my level best to guide you throughout the competition, help you open your first issue and your first Pull Request (I prefer to call it PR) and provide you some easy cheats which won't guarantee you a podium but will undoubtedly help you in enjoying the event to its fullest. The event is yet to pick up its pace (the coding period started on the 8th of March), but with approximately 6000 participants, the hype is definitely real. But don't get me wrong, GSSoC is solely meant to promote Open Source, and OSS means that it is open for everyone, so it doesn't matter if you are a GSSoC participant or not; it doesn't matter whether you have mastered your Tech Stack or not, all that matters is that you have decided to step into Open Source and trust me you are in for a treat. With these words, buckle up everybody, and let's talk about contributing to GSSoC or Open Source in general.

First step in GSSoC'21?

Well, first of all, you need to register in GSSoC, ensure that you perform all the formalities the organizers ask you to fulfill, join the official communication channels, and you are good to go!

How GSSoC works?

How does GSSoC work, you ask? It's quite simple. In layman's terms, multiple people apply to register their project under the banner of GSSoC, the owners (called Project Admins) of the projects that are accepted than are assigned a bunch of mentors (usually 2-3) who are tasked to help the Admins throughout the three months. Participants can contribute to these projects and earn points, and now you know where I am going with this, prizes are distributed based on points earned yadda yadda yadda.

How to choose a project?

Before choosing a project, we need to ask ourselves a few questions:

What languages, tech stack, framework. Am I proficient in? None is also acceptable, to be honest.
What languages, tech stack, framework. I want to learn/master or at least get the hang of it after these three months?

The best part about GSSoC is the number of projects that one can choose from; with nearly 100 projects using various tech stacks to select from, GSSoC has something for everyone. Fond of Web development, multiple projects are using MERN, MEAN, MEVN, ROR stack. Love Machine learning and Deep Learning, there are projects which specifically focus on classification and prediction. Love Python? Do take a look at multiple Flask and Django projects. Willing to master DS and Algo, GSSoC has got you covered. From beginners to advanced, you will for sure find something. You don't the coding and debugging part? How about Documentation? Nearly every project needs that.

So now we know our preferred tech stacks, let's look for projects on the GSSoC official website. As for now, you are allowed to contribute to any project, make a list of all the projects you find interesting, star them (to show your appreciation), and then we can start hunting for issues to solve.

Every Project on GitHub has an Issues section; go to the issues section and go through all the issues which have GSSOC21 label and are not assigned to anybody (it's crucial), while most of the projects prefer to have one person working or assigned to an issue, some projects might not follow this workflow; hence it is always recommended to ask the mentors and admins of the project before working on an issue. After you have found the issue you think you can solve, leave a comment like _ "Hey there, I think I can solve this issue, I will use this scheme, and will probably take this much time, "_ and then wait till the issue is assigned to you, this is important as this is not a race instead of a collaborative event. But wait, I can't find any issue to work on; what should I do now? No problem at all, go through the codebase once, try to find a bug (something that doesn't look right) which can be anything from a Typo to a Glitch fest, or try finding a missing feature (Something that is missing), open an issue for the same, and you are good to go, but remember to wait for the Admins and mentors to go through your issue once.

So finally, the issue has been assigned; the mentor has labeled it as GSSOC21 or similar and also assigned the difficulty level; ask the mentor to put them if the labels are missing. Now what?
Here is where the Best Part start. It's time to get your hands dirty. Now in the subsequent steps, I will tell you how you should make your PR.

The Dirty Work

Forking Projects

Let's start by Forking the Project.

This will create a Local Copy of the Repository on your GitHub Profile.

Cloning

Now we can start with cloning the Repo in our local system. Moreover, it is recommended to keep the reference to the Original Project in upstream.

git clone https://github.com/<your-username>/<repo-name>  
cd <repo-name>  
git remote add upstream https://github.com/<upstream-owner>/<repo-name>

Updating Copy

You might need to update our copy (if you forked earlier and the project had gone through changes); for that, we can use two methods.

Merge (Not preferred)
Rebase (Preferable)

git remote update
git checkout <branch-name>
git rebase upstream/<branch-name>

Branching

Our fork and the local copy are up to date; now it's time to work on the issue assigned to you.
There is a general non-breaking rule, you should never make a PR from the master, although this won't break anything, but it is a general practice and is very helpful if you mess up the commit history, so first of all, let's checkout to a new branch.

# It will create a new branch with the name Branch_Name and switch to that branch 
git checkout -b branch_name

Notice that you checkout to the new branch from the initial branch only.

So, suppose if you were in branch master and checked out to foo and then again used the command to checkout to bar. The branch is made from foo, not master. (Confusing? Never mind, as a general rule of thumb, always ensure to checkout to master using command whenever you are going to work on a new issue).

Working Remotely

Now get your hands dirty, code, edit and debug.

All set? You proofread, right? Do it once more.

Now, let's tell git to track the new files.
Let's start with a git status to check what has changed.

git status

Commit

After you've made changes or made your contribution to the project, add changes to the branch you've just created by:

# To add only a few files to Branch_Name
git add <some files>

# To add all new files to branch Branch_Name  
git add .

To commit, give a descriptive message for the convenience of the reviewer by:

git commit -m "message"

Always write a sensible commit message; it's a good practice and more comfortable for a 3rd person to comprehend.

Push the Commits and Pull Request

You have completed the most challenging part; now, all you need to do is, Push the commits, make a PR sit back, take a deep breath and wait for your mentors to review the PR.

# To push your work to your remote repository
git push -u origin Branch_Name

After pushing the commits, this message will pop up:

Finally, time to make a Pull Request; the process is simple, give a proper title, and explain the changes you have made. This is what your PR should look like.

Remember Fixes #issue_num is very important.

But while you wait, why not start working on a new issue. Follow the same steps for any project, Fork Clone Branch Add Commit Push.

[Note: If you are going to work on a different issue in the same project, do checkout to master before making a new branch].

But what if your mentor is not satisfied? No pressure you have got this, usually, they also tell you some vital information, like what is lacking, what to change.

Checkout to the branch, make those changes, Add, Commit, Push.

Viola, you updated your PR with another commit. Way to go.

This is the general workflow of any GitHub contribution and applies to every project, so while you are at it, look for other organizations and repositories to contribute to, search for good-first-issues they are usually easy and one excellent place to start.

Soon I will make a blog about all programs like GSSoC, which will help you to take part in programs like GSSoC; who knows, you might grab a good result in that event, you can follow me so that you don't miss it.

But before we conclude, we need to discuss something essential. Some essential rules of Open Source which you must abide by because, after all, we are in the same boat and must help each other. Kindly keep these things in mind:

Be Nice, Be Respectful (BNBR)
Check if the issue you created exists or not.
Make good commit messages and document your PR well.
Always add Comments in your code and explain it at points.
Dynamic Input is always preferred over static Driver Code.
Always create a Pull Request from a Branch; Never from the master.
Follow proper Code conventions. Using i',j` in Loops shows a poor understanding of Code Quality. Use appropriate Variable, Function Names.
Code would be reviewed by Mentors before they are merged. Every good PR requires Reviews.

That's all, folks.

Thank you so much for sticking with me till here. All the images used are of the Project Rotten-Scripts. I am one of the mentors of the project and would love to have you over there as well. Feel free to hang around, open an issue, maybe. There are many such awesome projects in GSSoC. Like I have said already, start contributing ASAP.

Let connect; I love to get in touch with people who have a similar mindset, my LinkedIn.
For exclusive Tech Posts, check my Dev Profile.
Go through my GitHub, you might find something interesting.

All the images have been taken from Rotten-Scripts.

Vybhav Chaturvedi, Over and Out.