Defining Constants

00:00 Defining Your Own Constants in Python

00:03 Up to this point, you’ve learned about constants as a general concept in life, science, and programming, but now it’s time to learn how Python deals with constants.

00:13 First, you should know that Python doesn’t have a dedicated syntax for defining them. In other words, Python doesn’t have constants in the strict sense of the word.

00:22 It only has variables primarily because of its dynamic nature. Therefore, to have a constant in Python, you need to define a variable that never changes and stick to that behavior by avoiding assignment operations on the variable itself.

00:36 In this section, you’ll focus on defining your own constants, but there are some built into Python, and you’ll learn about them later on in the course.

00:45 So given that Python doesn’t have the strict concept of constants built into it, how do developers know that a given variable represents one? The Python community has decided to use a strong naming convention to distinguish between variables and constants.

00:59 You write the naming capital letters with underscores separating words as stated in the constants section of PEP 8, the Python style guide.

01:09 On screen, you can see a few examples of user-defined Python constants. Note that these are created in exactly the same way as you create variables. You’ve used a descriptive name, the assignment operator, and the constant specific value.

01:26 By using capital letters only you are communicating that the current name is intended to be treated as a constant, or more precisely as a variable that never changes.

01:36 So other Python developers will know that and hopefully won’t perform any assignment operation on the variable at hand.

01:45 Note that this is just a convention and it doesn’t prevent developers from assigning new values to the constant. So any programmer working on your code needs to be careful and never write code that changes the values of constants.

01:57 And remember, this rule applies to you as well.

02:01 Because Python constants are just variables, both follow similar naming rules with the only distinction being that constants use uppercase letters only. Following this idea, constant names can be of any length, consist of uppercase letters, include digits, but not as their first character, and use the underscore character to separate words or as their first character.

02:24 Using uppercase letters makes your constants stand out from variables. This way other developers will unambiguously recognize their purpose. As a general naming recommendation.

02:35 avoid abbreviated names when defining constants. The purpose of a constants name is to clarify the meaning of the constant value, so you can reuse it later.

02:45 This goal demands descriptive names. Avoid using single letter names, uncommon abbreviations, and generic names, such as number or magnitude. The recommended practice is to define constants at the top of any Python file right after import statements.

03:03 This way, people reading your code will immediately know the constant’s purpose and expected treatment.

03:10 Module level dunder names are special names that start and end with a double underscore. Some examples are seen on screen. These names are typically treated as constants in Python projects.

03:23 According to Python’s coding style guide PEP 8, module level dunder names should appear after the module’s docstring and before any import statements except for __future__ imports. On screen is a sample module that includes a number of dunder names.

03:50 Here __all defines upfront the list of names that Python will import when you use the from module import star import construct in your code. In this case, someone importing greeting with a wildcard import will just get the greet function back.

04:06 They won’t have access to dunder author, dunder version, and other names not listed under dunder all. The Python community strongly discourages this import construct commonly known as wildcard imports because it tends to clutter your current namespace with names that you probably won’t use in your code and makes reading it less clear.

04:31 In contrast, __author__ and __version__ have meaning only for the code’s authors and users, rather than for the code’s logic itself. These names should be treated as constants since no code can be allowed to change the author or version during the program’s execution.

04:59 Note that the greet function does access the __names__ but doesn’t change them.

05:08 On screen you can see how greet works in practice.

05:19 In general, there are no hard rules that prevent you from defining your own module-level dunder names, but the Python documentation strongly warns against using dunder names other than those generally accepted and used by the community.

05:32 The core developers may introduce new dunder names to the language in the future, so it’s best to avoid using them as then there will never be any chance of a clash.

05:42 In the next section of the course, you’ll see how you can put constants to action in your code.