In Python you can run a command that prompts a poem.
When you run this, you'll see this text appear.
""" The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! """
This poem has a history but one interpretation is that it's a list of lessons learned by the maintainers who were working on Python.
It turns out that the Python core library isn't the only library that does this! There's a whole bunch!
>>> from sympy import this """ The Zen of SymPy Unevaluated is better than evaluated. The user interface matters. Printing matters. Pure Python can be fast enough. If it's too slow, it's (probably) your fault. Documentation matters. Correctness is more important than speed. Push it in now and improve upon it later. Coverage by testing matters. Smart tests are better than random tests. But random tests sometimes find what your smartest test missed. The Python way is probably the right way. Community is more important than code. """
Scikit-Lego has a poem that contains a bit of humour. Whenever a contributor makes a significant contribution to the project they may also be asked to make a contribution to this work.
>>> from sklego import this """ Roses are red, violets are blue, naming your package is really hard to undo. Haste can make decisions in one fell swoop, note that LEGO® is a trademark of the LEGO Group. It really makes sense, we do not need to bluff, LEGO does not sponsor, authorize or endorse any of this stuff. Look at all the features and look at all the extensions, the path towards ruin is paved with good intentions. Be careful with features as they tend to go sour, defer responsibility to the end user, this might just give them power. If you don't know the requirements you don't know if they're met. If you haven't gotten to where you're going, you aren't there yet. Infinity is ever present, the unknown may be ignored, not everything needs to be built, not everything needs to be explored. Change everything and you'll soon be a jerk, you may invent a new tool, not a way to work. Some problems cannot be solved in a single day, but if you ignore them, they sometimes go away. There's a lot of power in simplicity, it keeps you approach strong, if you understand the solution better than the problem, you're doing it wrong. """
The human-learn project tries to convince users to write their own tools.
>>> from hulearn import this """ Why worry about state of the art, maybe it's time that we all admit. That one-size-fits-all suit, is not bespoke and usually does not fit. Computers can flow a lot of tensors, but they never really learn. Natural Intelligence is still a good idea, and Artifical Stupidity a valid concern. There are many ways to solve a problem, but don't let fancy tools go to your head. Why would you use a predefined solution, if you can create a custom one instead. """
>>> from icepickle import this """ Roses are red. Violets are blue. Linear models are simple, and might be enough too! Inspecting models is grand, understanding them makes you smart. Linear systems are not perfect, but they're a good place to start. Advanced Classifier Technology is out there, but it can be hard to understand. Make sure you read the Illusion of Progress, by David J. Hand. """
>>> from clumper import this """ When you start a package, you can wonder if you really should. But it can be a great idea, if code brings joy and the learning is good. Understanding all the rules, can quickly become a chore. But if you understand them well, you'll know which ones to ignore. Not every dataset is huge, premature optimisation is getting cliche. People might still like an api, if it brings clarity right away. Take a break once in a while, don't keep at it 'till the bitter end. Find some good names for your methods, the thesaurus is your best friend. """
Many of the listed projects were authored by the maintainers of calmcode, but we're curious to learn about more inspirational
this-poems. If you happen to know any that we should add, let us know.
Back to TILs.