Asabeneh's 30 Days Of Python: A Repository Walkthrough Before You Commit

What 30 Days Of Python actually is, and who it is written for

This is a curriculum, not a library. The repository root holds thirty numbered folders, from 01_Day_Introduction/ through 30_Day_Conclusions/, each containing a Markdown lesson file and, in many days, a separate exercise file. The README is a table linking every day to its Markdown file, plus a sponsor block and a note that the challenge "may take more than 100 days" and that you should "follow your own pace." That sentence is the honest framing of the whole project.

The audience is stated in Day 1: the challenge is "designed for beginners and professionals who want to learn python programming language." In practice the early days assume no programming background at all. Day 1 covers installing Python, the difference between a shell and a file, indentation, comments, and the seven built-in data types. By Day 21 you are writing classes; by Day 26 you are touching Flask; by Day 29 you are building an API. The curve is real, and the jump from Day 20 to Day 26 is the steepest part because the material shifts from language features to third-party packages.

Who it is not for: someone who already writes Python daily. Days 2 through 13 cover variables, operators, strings, lists, tuples, sets, dictionaries, conditionals, loops, functions, modules and comprehensions. If you have shipped Python, that is roughly a week of skimming. The value for an experienced developer sits in Days 15 through 29, where type errors, exception handling, regular expressions, file handling, the package manager, virtual environments and the web stack are collected in one place.

How the material is organised inside each day

Every day follows the same shape. A Markdown file opens with a table of contents, then prose explanation, then inline code examples, then a section headed with a computer emoji and the day number, containing exercises split into Level 1, Level 2 and Level 3. Day 1's exercise list is representative: Level 1 asks you to check your Python version and do arithmetic in the shell, Level 2 asks for a print of your personal details, Level 3 asks you to compute things like the area of a circle and the slope between two points.

The repository also carries supporting directories that the day table does not mention: data/, files/, images/, numpy_files/, test_files/, old_files/, python_for_web/, plus a mymodule.py and a mypackage/ at the root. Those exist so the lessons on file handling, modules and data can import or read something real instead of a hypothetical. If you clone the repository and run an example from Day 19 or Day 25, the paths in the code point at those directories, which is why you should work from inside the clone rather than copying snippets into a scratch folder.

Translations live in sibling directories: Chinese/, French/, German/, Greek/, Korean/, Persain/ (spelled that way in the repository), Portuguese/, Spanish/, Ukrainian/, Uzbek/, and a lowercase korean/ alongside the capitalised one. The duplicate Korean directories are a smell. The README links only Chinese, Portuguese, French and Greek from the header, so the other translations exist but are not advertised from the front page.

Installing nothing: how to start Day 1 from a clone

There is no package to install. The project is Markdown plus example scripts, so the setup is a clone and a Python interpreter. Day 1 walks through installing Python from python.org and installing Visual Studio Code, and the README points visual learners at the Washera YouTube channel with a link to a "Python for Absolute Beginners" video.

Clone the repository and confirm the interpreter version before you read anything else:

git clone https://github.com/Asabeneh/30-Days-Of-Python.git
cd 30-Days-Of-Python
python3 --version

The version check matters because the curriculum targets Python 3, and Day 1 asks you to run the same check as an exercise. If python3 is not found, Day 1's installing section is the place to fix that before continuing.

Then open the first lesson and run the first real snippet. Day 1's basic Python section uses the interactive shell for exactly this:

python3

At the prompt, the lesson's first examples are arithmetic and a print call. Type them and watch the shell echo the result, then exit with exit(). The point of the exercise is to separate the two ways you will work for the rest of the challenge: the shell for one-line checks, and a .py file for anything longer. Day 1 closes by having you create a helloworld.py in a folder of your choice, print your name, and run it with python3 helloworld.py.

From Day 20 onward the lessons introduce pip and virtual environments. The repository's own instructions for those are in 20_Day_Python_package_manager/ and 23_Day_Virtual_environment/. Follow them in order rather than installing packages globally, because Days 25 through 29 pull in pandas, Flask and a MongoDB driver, and mixing those into a system interpreter is how people end up with broken environments.

The exercise-answer problem and the missing test suite

The exercises are the reason to use this over a book, and they are also the weakest documented part. Levels are labelled, tasks are concrete, and many days ship a separate solutions file. But the README does not describe a convention for where answers live, and there is no automated checker anywhere in the repository. Nothing runs your code and tells you it is wrong.

That has two consequences. First, self-assessment depends entirely on you comparing your output against the solution file, and if a day has no solution file you are on your own. Second, the material is easy to read passively. The README itself warns that the challenge is "very demanding" and that you "need to allocate much time," which reads like an acknowledgement that people drop out. The Telegram group is offered as the accountability mechanism.

There is also no pinned environment. No requirements.txt at the root, no lockfile, no CI configuration visible in the top-level entries beyond .github/. Days 25 through 29 reference pandas, Flask and MongoDB, and the versions those lessons were written against are not declared. If a library changed its API since the lesson was written, the snippet may not run, and nothing in the repository will tell you that.

Where the curriculum stops being the right tool

The web and database days are introductions wearing the clothes of tutorials. Day 26 covers Python web, Day 27 covers MongoDB, Day 28 covers APIs and Day 29 covers building an API. Four days is not enough to learn Flask or to model data in MongoDB responsibly. If your goal is to ship a service, this sequence gives you vocabulary and a first working route, not the depth to make design decisions.

The same applies to statistics and pandas. Day 24 and Day 25 give you the shape of the tools. Neither day is a substitute for a statistics text or the pandas documentation, and the repository does not claim otherwise, but the day titles can create that expectation.

One more boundary: the repository has no releases. The recent releases list is empty, so there is no versioned artefact to pin, no changelog to read before a cohort starts, and no way to say "use the 2024 edition." You get the master branch as it stands. The last push to that branch was on 2026-09-10, so the material is being touched, but without releases you cannot tell what changed or when a lesson was last corrected.

Compared with the official Python tutorial and video courses

The alternative most people weigh against this is the official Python tutorial at docs.python.org, and the difference is structural rather than qualitative. The official tutorial is reference-shaped: it explains the language accurately and in order, but it does not set you tasks, does not grade difficulty, and assumes you will find your own projects. 30 Days Of Python inverts that. It is task-shaped. Every day ends with something to write, and the difficulty tiers let you stop at Level 1 on a bad day and push to Level 3 on a good one.

Against a video course, the trade is pace and feedback. Video gives you a person explaining and a fixed schedule; this repository gives you text you can search, code you can copy, and no schedule at all. The README's own "follow your own pace" is the honest description of both the strength and the failure mode: nothing external keeps you moving.

If you want a single difference to decide on, it is this. The official tutorial will still be correct in five years. This repository's early days are about the language and will age well, but its later days depend on third-party packages whose APIs move, and there is no release mechanism here to track those moves.

Licence, maintenance and the cost of keeping up

The repository does not state a licence in the available documentation. There is no LICENSE file among the top-level entries, and the README does not name one. That is a real gap, not a formality. Without a licence, the default copyright position applies and you do not have an explicit grant to reuse the text or the code in your own teaching material, internal training or commercial course. If you are an individual working through the days, this changes nothing. If you are an organisation planning to fork the lessons into an onboarding programme, resolve the licence question before you build on it. This is not legal advice; ask whoever handles that for you.

The maintenance picture is mixed in a specific way. The last push was on 2026-09-10, so the repository is not dormant. But there are no releases, so there is no upgrade path to reason about. The cost of adopting it is not a dependency upgrade treadmill; it is that you are reading a moving branch and any given lesson may have been edited since the last time someone reviewed it. Budget for that by pinning the commit you teach from, or by accepting that the text you read today may differ next month.

The translation directories add a second maintenance cost. A translation is only as current as the day it was written, and the README does not indicate which translations track the English day list. If you are not reading the English days, verify that the folder you are in covers all thirty before you plan a schedule around it.

Editorial conclusion

Adopt 30 Days Of Python if you are starting Python 3 from zero or filling gaps in fundamentals and you want exercises with visible answers rather than a video course. Do not adopt it as a reference for production library work: the Flask, MongoDB and API days are introductory, and the repository carries no test suite to tell you whether your code is right. Before you start, check three things: the licence file, which the repository root does not appear to contain; whether the translated folder for your language is current with the English day list; and whether the Python version installed on your machine matches the syntax in the early days. Read 01_Day_Introduction/readme.md first, because the top-level README is a table of contents and nothing else.

Frequently asked questions

Official sources

1. Asabeneh/30-Days-Of-Python on GitHub
2. Issues
3. README