Book Image

Getting Started with Python

By : Fabrizio Romano, Benjamin Baka, Dusty Phillips
Book Image

Getting Started with Python

By: Fabrizio Romano, Benjamin Baka, Dusty Phillips

Overview of this book

This Learning Path helps you get comfortable with the world of Python. It starts with a thorough and practical introduction to Python. You’ll quickly start writing programs, building websites, and working with data by harnessing Python's renowned data science libraries. With the power of linked lists, binary searches, and sorting algorithms, you'll easily create complex data structures, such as graphs, stacks, and queues. After understanding cooperative inheritance, you'll expertly raise, handle, and manipulate exceptions. You will effortlessly integrate the object-oriented and not-so-object-oriented aspects of Python, and create maintainable applications using higher level design patterns. Once you’ve covered core topics, you’ll understand the joy of unit testing and just how easy it is to create unit tests. By the end of this Learning Path, you will have built components that are easy to understand, debug, and can be used across different applications. This Learning Path includes content from the following Packt products: • Learn Python Programming - Second Edition by Fabrizio Romano • Python Data Structures and Algorithms by Benjamin Baka • Python 3 Object-Oriented Programming by Dusty Phillips
Table of Contents (31 chapters)
Title Page
Copyright and Credits
About Packt
Stacks and Queues
Hashing and Symbol Tables

A few useful tips

When writing functions, it's very useful to follow guidelines so that you write them well. I'll quickly point some of them out:

  • Functions should do one thing: Functions that do one thing are easy to describe in one short sentence. Functions that do multiple things can be split into smaller functions that do one thing. These smaller functions are usually easier to read and understand. Remember the data science example we saw a few pages ago.
  • Functions should be small: The smaller they are, the easier it is to test them and to write them so that they do one thing.
  • The fewer input parameters, the better: Functions that take a lot of arguments quickly become harder to manage (among other issues).
  • Functions should be consistent in their return values: Returning False or None is not the same thing, even if within a Boolean context they both evaluate to False. False means that we have information (False), while None means that there is no information. Try writing functions that return...