How to Program in Python - Episode One (DocStrings, Data Types, and Exception Handling)

In today's episode, we cover how to create docstrings, data types, and exception handling in the beautiful language of Python. This is the start of a playlist that I hope everyone can find joy in, let's start something special!

Songs featured:
- Song: DEAF KEV - Invincible [NCS Release]
Music provided by NoCopyrightSounds
Free Download/Stream: http://ncs.io/invincible
Watch: http://youtu.be/J2X5mJ3HDYE

Timestamps:
00:00 Introduction to the Course
00:35 Lessons covered Today
02:15 Chapter one: Docstrings
02:16 Question 1
02:55 Answer Q1
03:18 Question 2
03:50 Answer Q2
04:34 Question 3
04:44 Type Hint Defined
05:50 Answer Q3
06:08 Should I Type Hint or Define in Docstring?
06:44 Question 4
06:50 Answer Q4
07:30 Docstring Code Along
11:36 Docstrings on a Class
12:20 Docstrings in a Class Constructor
13:02 Really Cool Feature in PyCharm
13:50 Chapter two: Data types
14:28 All Core Data Types in Python (General)
22:56 Exception Handling at a Glance
23:26 Question 1
23:32 Answer Q1
24:09 Question 2
24:20 Answer Q2
24:56 Question 3
26:04 Exceptions and Errors Examples


Questions and Answer Section:
# What is a good use case of having a docstring(s)?
"""
1. Cover high-level overview of what you are trying to accomplish
2. Covers all of the parameters being passed in.
3. Covers the return type / object of the function or class.
"""

# What qualifies as a useful docstring?
"""
1. Displays existing patterns on the team / at the company
2. Could easily be interpreted by peers if you are not there.
"""

# If you have a docstring, do you also need to type hint in the function declaration?
"""
1. Encourage to use just parameter type hinting over docstrings
2. Other languages will require typed variable, so keeps you in that habit
3. No need to double down and do both, just do one or the other
"""

# Is Python a typed-language?
"""
No. Python is a dynamically typed language that interprets the data type of the object, once a value has been
instantiated for that object.
"""

# When should you be handling exceptions?
"""
Whenever you have a dependency on another application, method, or class, you will always need to catch it.
This will result in applications bombing out on the server and 500s otherwise :(
"""

# How exhaustive should my exception handling be?
"""
Should be indicative of what the exception is and why it was thrown. Should be easy for whoever is oncall to find the
issue without having to scramble for other engineers immediately.
"""


# Is catching all exceptions by a larger generic exception fine?
"""
Absolutely not. You will need to cover all of your bases if you are depending on an application to better understand
where things went wrong and how to resolve the issue from ever occurring again in the future.
"""