Structuring a Python Application (Summary)
You’ve seen example layouts for a number of different application types:
- One-off Python scripts
- Installable single packages
- Larger applications with internal packages
- Django web applications
- Flask web applications
You now have the tools to successfully prevent coder’s block by building out your application structure so that you’re not staring at a blank canvas trying to figure out where to start. Because Python is largely non-opinionated when it comes to application layouts, you can customize these example layouts to your heart’s content to better fit your use case.
These examples are neither hard-and-fast rules nor the only way to structure your application. With practice, you’ll develop the ability to build and customize your own useful Python application layouts!
Congratulations, you made it to the end of the course! What’s your #1 takeaway or favorite thing you learned? How are you going to put your newfound skills to use? Leave a comment in the discussion section and let us know.
00:00 This series of videos has talked about the file structure for your Python applications. I started off by showing you a single-file program and associated configuration files, moved up to larger applications that used modules, and then went to larger applications still that used multiple modules.
00:26 As I mentioned in the first lesson, this video is based on an article by one of my colleagues at Real Python named Kyle. As a result of this, I’ve been able to see the comments attached to the article so I can possibly anticipate some of your questions. Python really isn’t opinionated about file structure. As a result, there’s a lot of variation out there.
00:45 Desktop applications have their own intricacies. If you’re doing Tk or Qt, they both require to have modules structured in a certain way, and that will impact the layout. Packaging has never been Python’s strength; it’s always been handled through third-party libraries rather than in the built-in ones.
01:03 That means there’s been lots of opinions and lots of change over the years. There are currently a half dozen popular virtual env management tools out there, so I don’t expect this is going to stay static.
There’s pros and cons to this. The current directory that you’re in is
sys.path. This makes it really easy to import something in a simple script, but it also makes it easy to make mistakes when you’re packaging.
Putting things inside of a
src/ (source) directory forces you to test the installment and make sure that pieces are working properly. Unfortunately, some IDEs have problems with this structure, so it can make your life a little more complicated depending on what tools you’re using. And, the Python packaging authority does not currently use this mechanism. The debate rages on though. Throughout the lessons, you’ve seen me using
setup.py. In addition to
setup.py, there’s something called
setup.py is an actual Python program—
setup.cfg is just a data file.
You can specify a lot of the same type of configuration in a CFG file as you can inside of
setup.py. The file format uses an INI style declaration and it’s an easier way of providing defaults, so if your installer of choice wants to be able to give the person doing the installation some choices, using a text file to provide those choices and then allowing them to be overwritten is easier. And although CFG is supported, it doesn’t seem to be as popular as
setup.py, but that might just be because I tend to spend a lot of my time looking at older code. Another variation is where to put the
02:44 Some programmers prefer to put this inside of the module directory instead of the project route. This works fine enough. If you don’t want to include your tests inside of your package object, it means you have to update your manifest files in order to make sure that they don’t get bundled.
03:08 You’ll see some of these variations out there as you go through other people’s code. What about the virtual environment? Where should you put it? Well, the short answer is: it kind of depends. This is mostly a personal preference, but the tools that you’re using may have different expectations.
One of the reasons to stick with fairly standard file structures is it makes it easier for you to use tools out there that have expectations.
tox is used for testing your program against multiple versions of Python and has expectations about your file structure and
twine is for uploading your package to pypi.org, if you’re sharing it, and it expects the distribution wheel created by
For large programs, it’s usually helpful to do a little bit of linting and formatting. There’s plenty of choice for linters and checkers out there:
flake8 are all very good tools.
Typically, the result is no one’s happy about what the code looks like, and that’s sort of the sign of a good compromise. There are also good tools out there to help you bootstrap your programs using scaffolding technology. Two common ones are
cookiecutter. That’s everything I wanted to say.
Become a Member to join the conversation.