PCAP Modules and Packages Practice Question
A module 'shapes.py' defines several classes: Circle, Square, Triangle. The developer wants to allow users to import only Circle and Square when they use 'from shapes import *'. Which mechanism should be used?
⚠ Common exam trap
Python Institute often tests the misconception that an underscore prefix makes a name truly private or that an `__init__.py` file alone controls wildcard imports from a single module, leading candidates to choose A or C instead of the correct `__all__` mechanism.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define a list variable named __all__ containing the string names 'Circle' and 'Square'.
The `__all__` variable in a module explicitly controls which names are exported when a client uses `from shapes import *`. By setting `__all__ = ['Circle', 'Square']`, only those two classes are imported, while `Triangle` is excluded. This is the standard Python mechanism for restricting wildcard imports.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Prefix the Triangle class with an underscore to make it private.
Why it's wrong here
Prefixing the class as _Triangle only marks it as private by convention; while from shapes import * would skip names that start with an underscore by default, this does not prevent direct access and does nothing to hide other public names like a stray helper function. The underscore is implicit and brittle compared to __all__, which explicitly declares the exact wildcard-import surface. Thus, an underscore is not a substitute for defining __all__.
- ✗
Use the import_explicit function.
Why it's wrong here
No function named import_explicit exists in Python's built-ins or standard library; the import system is driven by the import statement, the importlib module, and a module's own __all__ attribute. Even if a helper with that name existed, it could not alter what from shapes import * exports, because wildcard behavior is determined by the target module's namespace, not by an importer-side call. The correct solution is to define __all__ inside shapes.py.
- ✗
Create an __init__.py file in the same directory.
Why it's wrong here
An __init__.py file has no effect on a standalone module like shapes.py; it only marks a directory as a Python package and controls imports of that package as a whole. Placing __init__.py in the same directory does not change the star-import behavior of the shapes module, which is governed solely by the module's own namespace and __all__ attribute. Without __all__ in shapes.py, every public name defined there remains available to import *.
- ✓
Define a list variable named __all__ containing the string names 'Circle' and 'Square'.
Why this is correct
Setting __all__ = ['Circle', 'Square'] at the top level of shapes.py explicitly whitelists those two classes for wildcard imports; any other public name, such as Triangle, will be ignored by from shapes import *. This is the canonical Python mechanism for declaring a module's public API, and it is also honored by documentation generators and linters, making the module's intended exports unambiguous.
Go deeper
Related to this question
About these practice questions
This PCAP question is part of Courseiva's 169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCAP practice question is part of Courseiva's free Python Institute certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCAP exam.