Locked learning resources

Join us and get access to thousands of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Locked learning resources

This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Summarizing Examples

00:00 Congratulations, you have worked your way through five examples of internal objects starting with a single leading underscore. This video summarizes all those findings.

00:12 So we start with the overall table, the structure. You have a package that consists of several modules and a module can have several objects such as constants, variables, functions, and classes, and classes can have several members, attributes, and methods.

00:29 And then we have seen five examples covering all these points.

00:34 The first example we saw a constant and a function. You will remember _PI and _validate. They were internal within the shapes.py module and they were non-public outside of the shapes.py module, so it was okay to use _PI and _validate within the shapes.py module, and we did in the classes Circle and Square.

00:59 But it’s not a good idea to use these from outside of the shapes.py module, so _PI and _validate, despite the fact that they could be imported from shapes.py into the main .py file, for example, shouldn’t really be used in the main .py file.

01:20 Example two, we saw an internal variable _count, which was internal within the count.py module and it was therefore non-public outside of that module.

01:32 It was therefore okay to use _count within the count.py module, and we did in the increment(), the decrement(), and the get_count() public functions, but don’t use _count from outside count.py.

01:48 There was also a note that exporting global variables is usually not a good idea, and there was a link to the Real Python tutorial that gave you some more information there.

02:00 In example three, you built the _utils.py internal module. It is internal within your package, but it is non-public outside of your package, so it’s okay to use _utils within your package, but don’t use _utils from outside of your package.

02:20 In your package, we had a number of modules. One of them was main.py and there was _utils.py and a few others. So for example, it would be okay to use main.py from outside your package because that doesn’t start with an underscore so that is a public module, but _utils is not a public module.

02:42 Example four, we saw a class _Utils, which is an internal class within the classes.py module. It was therefore non-public outside of the classes.py module.

02:55 So as before, it was okay to use _Utils within classes.py, but it was not okay to use it from outside classes.py. And in example five, we saw class attributes and class methods.

03:12 We saw _attribute and _helper() methods. They were internal within ClassA and they were non-public outside of ClassA, and therefore it was perfectly okay to use them within ClassA, but we shouldn’t really use them outside of ClassA, despite the fact that it’s actually possible.

03:33 And we looked at the fact that internal methods can be helper methods within a class, just as _validate was a helper function within the shapes.py module.

03:44 So now that you’ve fully grasped the idea of public and non-public and internal objects, you are ready to move on to wildcard imports in the next video. See you there.

Become a Member to join the conversation.