Book Image

Mastering Object-Oriented Python - Second Edition

By : Steven F. Lott
Book Image

Mastering Object-Oriented Python - Second Edition

By: Steven F. Lott

Overview of this book

Object-oriented programming (OOP) is a relatively complex discipline to master, and it can be difficult to see how general principles apply to each language's unique features. With the help of the latest edition of Mastering Objected-Oriented Python, you'll be shown how to effectively implement OOP in Python, and even explore Python 3.x. Complete with practical examples, the book guides you through the advanced concepts of OOP in Python, and demonstrates how you can apply them to solve complex problems in OOP. You will learn how to create high-quality Python programs by exploring design alternatives and determining which design offers the best performance. Next, you'll work through special methods for handling simple object conversions and also learn about hashing and comparison of objects. As you cover later chapters, you'll discover how essential it is to locate the best algorithms and optimal data structures for developing robust solutions to programming problems with minimal computer processing. Finally, the book will assist you in leveraging various Python features by implementing object-oriented designs in your programs. By the end of this book, you will have learned a number of alternate approaches with different attributes to confidently solve programming problems in Python.
Table of Contents (25 chapters)
Free Chapter
1
Section 1: Tighter Integration Via Special Methods
11
Section 2: Object Serialization and Persistence
17
Section 3: Object-Oriented Testing and Debugging

Why exec() is a non-problem

The previous section discussed eval(); the same considerations also apply to exec().

Generally, the set of available globals() is tightly controlled. Access to the os and subprocess modules, or the __import__() function, can be eliminated by removing them from the globals provided to exec().

If you have an evil programmer who will cleverly corrupt the configuration files, then recall that they have complete access to the entire Python source. So, why would they waste time cleverly tweaking configuration files when they can just change the application code itself?

One question can be summarized like this: What if someone thinks they can monkey patch the application by forcing new code in via the configuration file? The person trying this is just as likely to break the application through a number of other equally clever or deranged channels. Avoiding...