prof-rajeshs/level_1-python-programs

Purpose and Shape

This is a collection of standalone Python learning exercises with solutions, organized into two difficulty tiers. It is not an integrated application or package: each .py file is an independent executable example/problem solution.

Entry Points

Each problem file is a direct Python entry point, intended to be run individually with the Python interpreter. Representative files include:

• Level_1_Python Program with solutions/Level_1_Problem_01.py

• Level_1_Python Program with solutions/Level_1_problem_27.py

• Level 2 Python Program with solutions/Level_2_Program_01.py

There is no visible central launcher, importable application module, CLI dispatcher, or orchestration layer.

Level 1 Exercise Set

The primary beginner curriculum resides in Level_1_Python Program with solutions/. It contains numbered problem implementations, largely spanning 1–35:

• Level_1_Python Program with solutions/Level_1_Problem_01.py

• Level_1_Python Program with solutions/Level_1_Problem_16.py

• Level_1_Python Program with solutions/Level_1_Problem_35.py

Numbering is convention-based rather than enforced by a manifest; problem 27 uses a lowercase filename segment (Level_1_problem_27.py), which matters for case-sensitive paths.

Level 2 Exercise Set

More advanced exercises are isolated in Level 2 Python Program with solutions/, with programs numbered 1–16:

• Level 2 Python Program with solutions/Level_2_Program_01.py

• Level 2 Python Program with solutions/Level_2_Program_08.py

• Level 2 Python Program with solutions/Level_2_Program_16.py

This directory is a peer collection to Level 1, not a dependency layer or package extension.

Execution and Data Flow

The expected control flow is per-file: a user selects an exercise, executes its script, supplies any runtime input requested by that script, and receives output through the terminal. Inputs, intermediate values, and outputs are local to a single program invocation; no shared persistence, inter-problem data flow, or reusable domain model is evident from the repository layout.

Boundaries and Runtime

The material runtime is Python. The repository contains no dependency manifest, framework structure, container/deployment assets, database schema, API client layer, cloud infrastructure, or external-service integration. README.md is present but supplied without content, so the directory names and script naming establish the usable navigation and curriculum boundaries.

Maintenance Implications

Treat every numbered script as independently owned and runnable. Cross-cutting changes—such as a common runner, shared utilities, tests, or packaging—would be new architecture rather than modification of an existing platform. Preserve directory names with spaces and the Level 1/Level 2 separation because they are the repository’s effective organization and discovery mechanism.