I thought it did, but I think it needs a double-check. I'm using pytest-timeout.

Advanced

Here is a list of pre-commit checks that I typically use for my project:

• Linters: flake8, pylint. My choice: [flake8]. Additional flake8-plugins:
  • flake8-bugbear for detecting bugs and potential design problems
  • flake8-builtins for verifying that builtins are not used as variable names
  • flake8-comprehensions for writing better and consistent comprehensions
  • flake8-debugger for checking that there are no forgotten breakpoints
  • flake8-eradicate to avoid “dead” or commented code
  • flake8-logging-format for consistent logging
  • pep8-naming for verifying that PEP8 naming conventions are followed
  • tryceratops to avoid exception anti-patterns
• Type checking: mypy. My choice: [mypy]
  • types-click-spinner
  • types-requests, types-tabulate, types-toml
• Auto-formatters:
  • isort for sorting imports
  • autoflake for removing unused imports
  • black for formatting the rest of the code.
• Python auto-update: pyupgrade tool to automatically upgrade syntax for newer versions of the language.

Also, make sure to fix highlights.

It turns out that the"".lstrip() method doesn't work as we were expecting. It removes all the characters that match the letters provided to the lstrip(). Here is the example.

In [2]: "aaaabbbbbccccd".lstrip("cba")
Out[2]: 'd'

I think we should replace it with a simple string slicing.

Also, make sure that the ipytest indeed works as expected. It can be done by restarting the kernel and executing the test cell right away.

Basic

• Reading files:
  • open, close
  • binary vs text mode (encoding)
  • read, append, overwrite modes
  • writing and reading with iteration or with read_lines/write_lines
• Reading and writing csv with the built-in csv module
• Managing Paths with pathlib
  • creating paths
  • resolving paths
  • path manipulation (suffix, appending, renaming, globbing, ...)

Advanced

• Streams with the io module
• Implementing file-like behaviour on other objects (adding open/close methods to other resources)
• Context managers for resource management (with keyword)
  • understanding context managers
  • implementing context managers to handle custom resources
• Databases
  • local databases with sqlite3 module
  • database querying with pandas (maybe, it's not part of Python stdlib)

We should add a few lines explaining how to download the archive with the tutorial

The tutorial states about type hints:

Python doesn't require you to explicitly declare a variable's type. However, when defining functions, you can add type hints in the function's signature.

Type hints improve code readability and can help catch potential type-related bugs early during development.

The Python interpreter does not enforce type hints and will not check them during runtime. Type hints are primarily intended for improving code readability, serving as documentation for developers, and making IDEs much more helpful when writing code.

However, the question "What is the purpose of type hints in Python function definitions?" is not correctly answered, when the answer "To make the code more readable" is selected.

The following notebooks don't have a working TOC (links are broken):

• Input-Output
• Functional programming

Control flow exercises often need lists, but there are no examples or exercises to introduce people in list manipulation.

The problems with find the pair (Exercise 2) have a misleading return type. Shall we return a list or just a number?
It seems we need to return the product of the triple, but it is not so clear from the question.

Basic

• Python modules to split a python program for easier maintenance and code reuse.
• Creating a module and importing its content (note on import *)
• Package - a collection of python modules.
• Intra-package references (from ./.. import)
• Making a python package installable (pyproject.toml)
• Releasing python package on PyPI.

Advanced

• Executing modules as scripts (if __name__ == "__main__")
• Importing * from a package (use __all__).
• Setting up Python package dependencies
• Dependencies and optional dependencies of a Python package
• Python management tools: setuptools, flit, hatch, poetry.

If people need assistance with other environments, we can prepare a support session another time.

Basics

• What's Python Global Interpreter Lock

Advanced

• Multithreading vs multiprocessing
• Process pool and thread pool executor
• Python can only run I/O bound threads concurrently, CPU bound work is blocking (GIL)
• Alternatives to Multithreading:
  • Asyncio
  • Coroutines
• Synchronisation primitives:
  • Channels
  • Locks
  • Mutexes

Basics

• Looping constructs and iterables
• Altering and breaking out of loops: continue, break
• if-else construct and problems with nesting too many branches
• The else clause for loops

Advanced

• The match construct (Python 3.10.x) to avoid nesting
• Pros & cons of looping (when it's better to use functional programming methods)
• Recursion and its limits
• The built-in Exception class
• Built-in exceptions: TypeError, NameError, KeyError, ZeroDivisionError, OverflowError
• The try-except-finally construct
• How to handle exceptions to have a stack trace useful for debugging

The solution to exercise 3 on strings is not strictly correct:

I provide a solution that is

my_string.split()

One might also think of the following solution that could also work:

my_string.split(" ")

However, those two approaches work differently with an empty string:

"".split()  # returns an empty list []
"".split(" ")  # returns a list with an empty string [""]

We should either adapt the description or change solution to .split(" ").

Basics

• Writing a function: parameters, body, return statement
• Annotations and docs
• Parameters vs Arguments
• Position and keyword arguments
• How Python executes a function (definition vs execution)
• Scope (global and local)

Advanced

• Functions with mutable arguments and default values
• Functions are objects
  • Functions can be stored in data structures
  • Functions can be passed to other functions
  • Functions can be nested
  • Functions can capture the local state (closures)
  • Functions can return other functions (decorators)
• Functions and iterables: unpacking, the * and ** operators, *args and **kwargs
• Lambda expressions and their purpose/limitations
• Pure vs impure function (with side-effects), best practices with separating the two kinds

Currently, we're using pytest to test users' answers against reference solutions. However, we want to enhance the feedback provided to users when their answer is incorrect or doesn't match the reference solution. We would like to explore alternative approaches that encourage users to explore diverse solutions and improve their coding skills while still receiving helpful guidance.

Here are some potential approaches to consider:

1. Compare function signatures (we're sort of already doing that)
2. Leverage Abstract Syntax Trees (AST)
3. Test multiple reference solutions
4. Create custom pytest assertions

A couple of comments to (2) and (4).

Abstract Syntax Trees (AST)

We can use Python's ast module to parse users' code and the reference solutions into ASTs. By comparing the structural similarities between the two ASTs, we can provide a useful feedback while allowing for diverse solutions. This encourages users to follow good coding practices without adhering to a specific solution.

Custom pytest assertions

Develop custom pytest assertions that evaluate users' code based on specific criteria, such as the proper use of loops, conditional statements, and other coding constructs. This way, we can provide feedback based on the user's understanding and application of core programming concepts.

Show the stdout even if the test suceeds...I think we had this in an earlier version.

Basic

• Iteration and filtering using comprehensions
• Reduction (useful for "sliding window" operations)
• Combining iterators with itertools:
  • tee
  • zip
  • map & filter (lazy methods)
  • generalized zip
  • transposing

Advanced

• Lazy computation and iteration with generators (yield)
• itertools:
  • infinite iterations
  • groupby
• functools:
  • caching
  • partial application (currying, partial objects)
  • single dispatch

When we evaluate a cell, we could check for some of the most common mistakes that aren't syntax-related.
Example we saw during the course:

• Assigning a new constant value to the the function input variables
• Printing as a last statement in the function body
• Missing return statement
• Returning a "print" statement
• Returning None

Lines 67-80 of tutorial/tests/test_basic_datatypes.py might be wrong. We should use math.isclose and maybe provide better test cases

We should maybe add a few lines to the FAQ explaining the course participants how to run the test. We should explicitly warn them against modifying the signature or the name of the solution function and tell them that the cell magic will call the function for them, therefore there is no need for calling the function explicitly.

The Task is to count words in a file, but it appears that the correct solution is to simply count the number of lines in that file.

I noticed several people did not seem to understand that the input needed for their solution are already available in the scope of their function. We should write this more explicitely

Important
We agreed on the following definition of "advanced": something that requires the understanding of and build on what we said in the Intro Tutorial. We are assuming that all the participants are comfortable with every Intro topic.

Advanced topics

• #12
• #124
• #121
• #122
• #10
• #123

Python Libraries

• #144
• #147
• #143
• #146
• #142
• #145
• sympy
• ipywidgets
• traitlets
• numba
• asyncio
• ase
• pymatgen
• toml/yaml
• pydantic
• subprocess

E.g. last cell of "Paths" in "File I/O":
type([f for f in path.glob("*")])

Instead of finding the name of the notebook, ipynbname.name() raises a FileNotFoundError when working with a local ipython kernel in visual studio code. I suggest using the old way of loading tests where we manually specified the module where they resided. I anyway would prefer a mode explicit solution.

• Modify the timetable to put intro first
• Extend information on tests
• Add intro to Jupyter Lab:
  • Interface
  • Create/delete folders and files
  • Open Terminal

Look into the docs of ipywidgets

Main topics

• #3
• #7
• #5
• #4
• #6
• #8
• #11

It might be better to enumerate the notebooks (starting with 0-intro.ipynb) so that they are sorted in GitHub as well

Basic

• Dynamic typing in Python (vs static)
• build-in data types
  • floats and integers
  • strings
  • booleans
• Basic operations with the build-in data types
• Data structures
  • lists and tuples
  • dictionaries
  • sets
• Mutable vs immutable types (the id function)
• Basic operations with data structures.

Advanced

• Explicit type annotation in Python. For more details see PEP3107, and PEP484
• Typing package
• Collections module
  • deque
  • object counters
  • name tuples
• Best practices (exercises showing how using appropriate types is beneficial in some cases).
  • list vs set vs dict
  • deque

As discussed today with @edoardob90. We are trying to get test suites to run automatically with some cell magic.
Please have a look at the branch testsuite. Unfortunately I am not able to create a merge request because I accidentally pushed these changes to the main branch...let me know if you have a way to fix that other than my kludges.

Currently, in many notebooks, the exercises are placed at the end, and they are often quite hard.

It would make more sense to do more "intermediate" exercises after we cover each topic to better prepare the students for the hard ones.

This will also suggest the students go through each topic more thoroughly.

Here is the list of notebooks that need to be adapted:

• #118
• Control flow
• Input-Output
• Functional programming
• #117

Basics

• Creating a class: a blueprint for objects
• Methods and attributes
• Objects instantiation
• Special methods and the Python Data Model (a tour or __dunder__ methods)
• Duck-typing

Advanced

• The @property function to define attributes (setters and getters)
• About private attributes: comparison with OOP languages like C++/Java
• Inheritance
• Write better classes with dataclasses and attrs

I noticed that most notebooks don't use the cell magic %load_ext tutorial.tests.testsuite. We should add it at the top of every notebook. However, we also should remind people to run all cells above before working on their exercises, otherwise this won't work.

When running the tutorial we assumed that many things are obvious in Jupyter, but it turned out not to be the case. Users with no experience in Programming might still have trobles operating it.

I think a short introduction might be very helpful here.

Inspiration can be taken from here: nanotech-empa/general-issues#5

This refers to the exercise on Modules and Packages. Just to avoid that students add unwanted files to the git repo.

To calculate the change of a moon's velocity, the description states:

If Gx = 5 (the x position of Ganymede) and Cx = 3, then Ganymede's x velocity changes by +1 (because Gx > Cx), and Callisto's x velocity must change by -1 (because Cx < Gx).

In order to reproduce the given example after 10 steps, I had to change sign of the "force", i.e. Ganymede's x velocity has to change by -1. It seems this is catched in the solution by the negative sign in

self.velocities[n] -= delta

This test doesn't seem right:

For example, the line below seems not to be needed:

flavors = # TODO: create a tuple containing the flavors

Once #14 and #15 are merged, we should move some text that introduces unpacking and parallel assignment from "functions" to "basic datatypes".

We can collect any feedback/suggestion here. You should also be able to modify the survey with the link I sent by email.