Too clever, too much magic. I remember I used to create such things in my projects in my earlier days as a dev and was quite proud of how compact things were an

Too clever, too much magic. I remember I used to create such things in my projects in my earlier days as a dev and was quite proud of how compact things were and how much I understand my way around the language that I was able to come up with it. But at the end of the day, these things have a much higher price than it seems at first. Sparing a few lines here and there is not worth confusing your code's readers or yourself in a year. Standard established "pythonic" solutions are preferable. Some are nice functions, I guess all of us have our collection of utils that we carry around projects and it's certainly nice to have some of them collected in an installable library. But I'd prefer to have them separately in small, separately installable modules, similar to "more_itertools". delegates: Maybe it's useful for auto-completion in notebooks. store_attr(): Too confusing. Avoiding subclassing boilerplate: don't, it's too confusing. Type dispatch: perhaps, but I think isinstance is okay too. A better version of functools.partial: Ok, docstring is kept. Could be even changed in the standard library. Composition of functions: Okay, could be an addition to functools in the standard library. A more useful __repr__: Good. Monkey Patching With A Decorator: Please don't. A better pathlib.Path: I don't think loading pickle should be a method of Path objects. I already dislike pathlib putting read_text as a method of Path. Why not Path.read_jpeg_image()? Path.save_mp4_video() etc. Also don't monkey patch Path please. Self: too confusing, little upside to it. It makes things look like the function is being called, while actually only a lambda is produced. Too much magic. in_notebook(), in_colab(), in_ipython: Useful. The L list: the numpy style indexing is nice, but you may as well create a numpy array.