In my previous post, Python: Scope, I touched on the topic of Shadowing. In this post I’ll be delving deeper into it.

As Wikipedia says, variable shadowing occurs when a variable declared within a certain scope (decision block, method, or inner class) has the same name as a variable declared in an outer scope.

There are some interesting debates on whether shadowing is a bad thing or not in this StackOverflow Q&A as well as this one. In a nutshell, there are three trains of thought:

1. It’s fine to use shadowing.
2. You should avoid shadowing by ensuring all names are unique.
3. You should avoid shadowing by using functions.

Let’s now run through each of these options to see how they work.

Continue reading →

Scope is the term used to define the location(s) in which Python searches for a name to object mapping (e.g a variable).

As described in this StackOverflow post, Python uses the LEGB Rule to locate a definition. LEGB stands for:

• L, Local — Names assigned in any way within a function ( def or lambda)), and not declared global in that function.
• E, Enclosing-function locals — Name in the local scope of any and all statically enclosing functions ( def or lambda), from inner to outer.
• G, Global (module) — Names assigned at the top-level of a module file, or by executing a global statement in a def within the file.
• B, Built-in (Python) — Names preassigned in the built-in names module open,range,SyntaxError,...

In a nutshell, Python will first look at the local scope for a name to object mapping (e.g people = 5). If it cannot find one, it will continue going up the hierarchy until it finds one. If it doesn’t find a mapping, it will raise an exception.

To shed some more light on this let’s take a step back and analyse each of the points listed above. I’ll do so in reverse order because that is the way we write Python code, as you’ll see in a moment.

Continue reading →

A lot of Python books often mention that “everything in Python is an object”, and “objects are first class citizens”, but they don’t always explain what that these things actually mean. Let’s try to fix that up now.

Everything in Python is an Object

Dive Into Python gives a great explanation:

Different programming languages define “object” in different ways. In some, it means that all objects must have attributes and methods; in others, it means that all objects are subclassable. In Python, the definition is looser; some objects have neither attributes nor methods (more on this in Chapter 3), and not all objects are subclassable (more on this in Chapter 5). But everything is an object in the sense that it can be assigned to a variable or passed as an argument to a function (more in this in Chapter 4).

This is so important that I’m going to repeat it in case you missed it the first few times: everything in Python is an object. Strings are objects. Lists are objects. Functions are objects. Even modules are objects.

Continue reading →

There are plenty of articles on the internet that attempt to explain what  if __name__ == "__main__" is and what it does, but (in my humble opinion), the examples are too complex more often than not. With that in mind, this post is aimed at being the most simplest explanation on the planet! :)

What does it do?

This statement is used when you want your code to be used as both a standalone script, as well as a module that can be imported and used by other scripts.

For example, if it is run as a standalone script, you may want to provide a menu to ensure users input all of the necessary information. On the other hand, if it is being imported as a module, perhaps you’d like to avoid the menu all together and instead only use the functions contained the script (e.g func1 in the example below).

Continue reading →