Minimum Viable Python

Ask not what you can do for the REPL.

Ask what the REPL can do for you.

Near the end of 2021 I got a “value buyer’s” computer, in other words, a bit more powerful than my current need. I got a stack of python books, too, some of them pretty think.

Note

Ok, ‘think’ was a typo, I meant ‘thick’. But it does remind me that Alan Downey’s book ‘Think Python’, is now in its second edition.

The thin one, though, was thick for a book of one-line-long programs. The thing about a one-line program is that, unless it’s YOUR one line, it may be dense, complicated, unreadable and hard to explain. Perfect for a book, but easy to set aside until … dot dot dot …

… you type “import this” at the python REPL.

I thought that would be a great way to start, and after 18 detours into various ways this might be deployed, I finally opened it up, typed

% python3

and then, finally

>>> include this
  File "<stdin>", line 1
    include this
            ^^^^
SyntaxError: invalid syntax

Naturally, this was wrong, and if YOU forget to use “import” instead of “include”, that is the error YOU will get too.

Movin’ right along… “import this”, and here is your Python ‘Easter egg’.

>>> import this


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 list is 19 out of 20, the last one left by Tim for Guido to fill in. What was it? You tell me and we’ll both know! The python motto, “There should be one— and preferably only one —obvious way to do it.” is already in the list

This has been codified and placed in the public domain, as part of Python Enhancement Proposal number 20, aka PEP-20, created 19 August 2004, with a reference to a discussion from the end of the past millenium, i.e. just before Y2K.

What is that number 20?

The fastest way to do something is not to do it!<<

--- title: "Import THIS" author: "George Girton" date: "2022-05-11" categories: [python, code, errors] image: "hello_kitty_wave-06846.jpg" --- # Minimum Viable Python ### Ask not what **you** can do for the REPL. ### Ask what the REPL can do for **you**. Near the end of 2021 I got a "value buyer's" computer, in other words, a bit more powerful than my current need. I got a stack of python books, too, some of them pretty think. ::: {.callout-note collapse="true"} Ok, 'think' was a typo, I meant 'thick'. But it does remind me that Alan Downey's book ['Think Python'](http://www.allendowney.com/wp/books/think-python-2e/), is now in its second edition. ::: The thin one, though, was thick for a book of one-line-long programs. The thing about a one-line program is that, unless it's YOUR one line, it may be dense, complicated, unreadable and hard to explain. Perfect for a book, but easy to set aside until ... dot dot dot ... ... you type "import this" at the python REPL. I thought that would be a great way to start, and after 18 detours into various ways this might be deployed, I finally opened it up, typed ``` bash % python3 ``` and then, finally ``` python >>> include this File "<stdin>", line 1 include this ^^^^ SyntaxError: invalid syntax ``` Naturally, this was wrong, and if YOU forget to use "import" instead of "include", that is the error YOU will get too. Movin' right along... "import this", and here is your Python 'Easter egg'. ``` bash >>> import this 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 list is 19 out of 20, the last one left by Tim for Guido to fill in. What was it? You tell me and we'll both know! The python motto, "There should be one--- and preferably only one ---obvious way to do it." is already in the list]{.aside} This has been codified and placed in the public domain, as part of Python Enhancement Proposal number 20, aka PEP-20, created 19 August 2004, with a reference to a discussion from the end of the past millenium, i.e. just before Y2K. ## What is that number 20? > > The fastest way to do something is not to do it!\<\<