Practical_DL: a week-by-week deep learning course repo, and what its branch layout means for you
DL course co-developed by YSDA, HSE and Skoltech
At a glance
- What is it?
- The YSDA, HSE and Skoltech deep learning course ships as Jupyter notebooks organised into week folders on a fall26 branch. It is course material rather than a library, so the decision is whether its syllabus and notebook format fit how you learn or teach.
- Who is it for?
- Adopt it if you want a lecture-and-seminar sequence you can run locally or in Google Colab and you are willing to work from the fall26 branch rather than a tagged release. Skip it if you need a maintained library, an English-language support channel, or a syllabus that is complete at the moment you clone it, since the README itself marks the syllabus as still being updated.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Practical_DL actually is: a syllabus in folders, not a package
The repository is the supplement to a Deep Learning course taught in the fall of 2026, co-developed by YSDA, HSE and Skoltech. Its primary language is Jupyter Notebook, and the README states that "Lecture and practice materials for each week are in ./week* folders." That single sentence defines the whole structure: there is no installable module, no importable API, no versioned release. You get a directory tree of notebooks plus per-week readme files that explain how to run the assignments, either locally or in Google Colab.
The intended audience is a student enrolled in the course, or someone reproducing its sequence independently. The README points to a Telegram chat described as the russian-speaking HSE track, and to a wiki page for deadlines and grading rules. Both of those are course administration, not software support. So the practical question for an outsider is narrower than for a typical open source project: does the notebook sequence teach what you need, and can you run it without the cohort around you?
The topics list names course, course-materials, deep-learning, lasagne and theano, which reflects the repo's history rather than its current state. The README's own week01 entry tells students to begin worrying about installing PyTorch, and week02's seminar is titled PyTorch basics. Treat the topic tags as archaeology.
The branch-per-iteration model and why fall26 is the branch you want
The default branch is fall26, and the README opens by pointing to the previous iteration: "For previous iteration visit the 2025 branch." That is the maintenance model in one line. Each teaching run gets its own branch, and the default branch moves forward with the current cohort. There are no retrieved releases, so there is nothing to pin against except a branch name or a commit hash.
This matters more than it sounds. If you clone the repository today you get fall26, which is the live course. If you want the version that a previous cohort actually completed, you switch to fall25. The two are not the same artefact, and the README does not promise that they are compatible in structure or in dependencies. For a self-learner this is mostly harmless. For anyone building a course on top of it, or citing it in a curriculum, the branch name is part of your citation.
The upside of this model is that the materials stay current with the frameworks being taught. The downside is that there is no stable snapshot with a changelog. If a notebook is edited mid-semester to fix a bug, your clone from last week and your clone from this week differ, and nothing in the repository tells you what moved.
Week 1 to week 3: what the syllabus commits to and where it stops
The README's syllabus section is explicit for three weeks and then stops. Week01 is an introduction covering backpropagation and adaptive optimization methods, with a seminar on neural networks in numpy and homework 1 released. Week02 is described as a catch-all lecture about deep learning tricks: dropout, batch and layer normalization, deep learning frameworks, plus a PyTorch basics seminar and homework 2. Week03 covers convolutional networks, including computer vision tasks, convolution and pooling layers, ConvNet architectures and data augmentation, with a seminar on training a first ConvNet.
Below week03 the README says "(to be updated)." That is the honest state of the document, and it is worth taking literally. Anyone evaluating the repository as a complete self-study path should check the actual week folders rather than the syllabus text, because the folders may contain material the README has not yet described. The reverse is also possible, and the README gives no way to tell which weeks are finished.
The progression itself is conventional and sensible. Numpy-first, then a framework, then convolutions. The numpy seminar in week01 exists so that backpropagation is something you write before it becomes something a library does for you. That ordering is the pedagogical argument of the course, and it is visible from the syllabus alone.
Running the notebooks: Colab, local installs, and the PyTorch dependency
The README says you can "complete all asignments locally or in google colab (see readme files in week*)." The per-week readme files are therefore the real setup documentation, not the top-level README. If you want to know what a given week needs, that is where to look.
The one dependency the top-level README names outright is PyTorch. Week01 includes the instruction to "begin worrying about installing pytorch" and links to issue 6 in the repository for install guidance. Week02 assumes it is working, since the seminar is PyTorch basics. So the practical setup order is: read the week01 readme, get PyTorch installed following the linked issue, then work through the numpy seminar before the framework seminar.
Beyond that, the supplied material does not list a requirements file, a pinned version set, or a supported Python version. Those may exist inside the week folders, but nothing in the README or the repository metadata confirms it. If reproducibility matters to you, that is the first thing to check in the folders before you plan around the course. A notebook course that tracks current framework versions is convenient in September and fragile in the following year.
Grading, deadlines and the parts that only work if you are enrolled
The README links to a wiki page titled Homeworks and grading (HSE), and to a Telegram chat labelled as the russian-speaking HSE track. Both are course operations. Deadlines, grading weights and submission mechanics live on the wiki, and the chat is where the cohort asks questions.
For an independent learner this is the clearest boundary in the repository. You can read the lectures and run the seminars, but the accountability structure, the homework deadlines and the peer support are tied to an institution and a language community. The README does offer a general channel for the technical side: "Any technical issues, ideas, bugs in course materials, contribution ideas - add an issue or ask around in the chat." That is a genuine open invitation to file issues against the materials, and it is the right route if a notebook breaks.
There is also a contributor list crediting named authors for specific blocks of material: the main track lecture videos, intro notebooks, generative model and autoencoder notebooks, PyTorch and NLP notebooks, image captioning materials, and variational autoencoder materials. The README notes that bugs were fixed and materials improved by students and volunteers, with PR authorship as the record. That is a useful signal about how the materials were produced, and it tells you where to look if a particular topic's notebook feels thinner than the rest.
Where it fits against fast.ai and the official PyTorch tutorials
The obvious comparison is fast.ai's course materials, which are also notebook-based and freely available. The difference in approach is the starting point. Practical_DL begins with a numpy seminar where you implement neural networks by hand before touching a framework, and only in week02 moves to PyTorch basics. fast.ai's materials are built the other way round: you get a working model in the first lesson and descend into the internals afterwards.
Neither order is wrong, but they suit different people. If you already trust that the framework works and want results early, the top-down route is less frustrating. If you want backpropagation to be something you have derived rather than something you have called, the Practical_DL ordering is the point of the course. A second comparison is the official PyTorch tutorials, which are task-oriented and versioned against a specific PyTorch release. Practical_DL is sequenced as a semester, which means it carries a teaching narrative the tutorials deliberately do not have, and in exchange it carries the fragility of any course tied to a moving framework.
The honest summary is that Practical_DL is a curriculum, and the alternatives are either another curriculum or a reference. Choose based on whether you want to be taught in order or to look things up on demand.
Licence, maintenance cost and what to verify before you commit
The repository is MIT licensed. That is permissive: you can reuse, modify and redistribute the materials, including in a commercial setting, provided the licence terms are met. This is a general description of the MIT licence and not legal advice; if you plan to build a paid course on these notebooks, read the licence text and the contributor attributions in the README, since the materials credit multiple named authors for specific blocks.
Maintenance cost depends on which side you are on. As a consumer, your cost is the cost of keeping a PyTorch environment working and re-checking notebooks when the default branch advances to the next fall. As an adopter who forks or teaches from it, you inherit the framework-tracking problem: the course follows current PyTorch, so notebooks that depend on specific APIs will need attention over time, and there is no release channel or changelog to tell you when that happens. The last push recorded is 2026-09-04, which is consistent with an active teaching term rather than a dormant archive.
The first thing to verify is the week folders themselves, not the README. Open week01 and week02, read their readme files, and confirm the PyTorch setup path described in issue 6 works on your machine. If those two weeks run, the rest of the course is a matter of following the same pattern. If they do not, no amount of syllabus reading will help, and the issue tracker is the correct place to say so.
Editorial conclusion
Adopt it if you want a lecture-and-seminar sequence you can run locally or in Google Colab and you are willing to work from the fall26 branch rather than a tagged release. Skip it if you need a maintained library, an English-language support channel, or a syllabus that is complete at the moment you clone it, since the README itself marks the syllabus as still being updated. Before committing, open the week01 and week02 folders and confirm that the PyTorch install instructions in issue 6 match your environment, because the course assumes you have PyTorch working by week two.
Community notes