These are things that less experienced Python programmers might not know about, but they're not at all uncommon. If anything, calling `super()` in a base class should be the default if you're designing a framework where you expect people to use mixins (or even just explicitly intend for them to derive your classes, really).
Creating blank `__init__.py` files has basically become standard because the use cases where you'd prefer to omit them don't work well with packaging tools (since everything will be in `site-packages` anyway; most people also aren't going to install multiple things from a common namespace that you publish; adding those files helps build backends and other tools understand your project layout; etc.). On the flip side, the use cases for writing something in `__init__.py` should be evident from just considering the fact that it's possible. (It's also a useful refactoring tool; if you are planning to make a package but don't know what all its modules should be yet, you can start by turning an existing `foo.py` into `foo/__init__.py`.) Preemptively importing from `__init__.py`, though, is not always a great idea; it represents extra up-front import time that clients can't opt out of. (This has a lot to do with why Pip takes a significant amount of time even when it ultimately determines that it hasn't been asked to do anything.)
Preferring relative imports is, if anything, not common enough, but is certainly common among people who know what they're doing.
As for class/static/instance methods:
> When should we use class or static methods? Here are some basic guidelines I found.
The use cases more or less derive directly from their differences. But if you're going to cite sources for this, it's a crying shame to leave out Raymond Hettinger's "Python's Class Development Toolkit" (https://www.youtube.com/watch?v=HTLu2DFOdTg).
Creating blank `__init__.py` files has basically become standard because the use cases where you'd prefer to omit them don't work well with packaging tools (since everything will be in `site-packages` anyway; most people also aren't going to install multiple things from a common namespace that you publish; adding those files helps build backends and other tools understand your project layout; etc.). On the flip side, the use cases for writing something in `__init__.py` should be evident from just considering the fact that it's possible. (It's also a useful refactoring tool; if you are planning to make a package but don't know what all its modules should be yet, you can start by turning an existing `foo.py` into `foo/__init__.py`.) Preemptively importing from `__init__.py`, though, is not always a great idea; it represents extra up-front import time that clients can't opt out of. (This has a lot to do with why Pip takes a significant amount of time even when it ultimately determines that it hasn't been asked to do anything.)
Preferring relative imports is, if anything, not common enough, but is certainly common among people who know what they're doing.
As for class/static/instance methods:
> When should we use class or static methods? Here are some basic guidelines I found.
The use cases more or less derive directly from their differences. But if you're going to cite sources for this, it's a crying shame to leave out Raymond Hettinger's "Python's Class Development Toolkit" (https://www.youtube.com/watch?v=HTLu2DFOdTg).