Python – Formal Definition of ‘Pythonic’ Beyond PEP8

python

For me as python programmer having a formal definition for the term "pythonic" would be much more important and less subjective compared to asking more rhetoric (non-formal) questions. This may lead to better communication by argumentation being less subjective (as discussed in here).

PEP8 by Guido is assumed as a starting point despite of some religious dogmatism (e.g. PEP20 is more axiomatic, shorter and simpler, but has no code). Having identified minimalism, readability (human comprehension) and unambiguity (explicit code) is actually the same as paraphrasing PEP20. But is it possible to rewrite zen of python in python? Obviously print('Beautiful is better than ugly') does not capture python in python 😉 Any thoughts on this?

Ultimately I would like to get closer to more logical or mathematical interpretation of the matter. Argument in form of the code answering why family of snippets A is pythonic compared to family of snippets B is also acceptable.

EDIT If possible try to reduce your answer to the following outline.
Let us consider all possible syntactically correct program texts generated by some procedure (e.g.). Please note that we a considering only programs written in python (which is a formal language with respective grammar). Also being syntactically correct does not mean semantical correctness (programs may be buggy or without any obvious purpose). Further we observe (assume) that ultimate family POmega of all syntactically correct programs in python must contain a subset of programs which are called Pythonic. Now in order to argue about what does it mean to be pythonic we will use a formal method – another language called Reason which would be less ambiguous (consistent, complete) than natural language. We will define a mapping from programs in Omega into Reason. Such mapping we will call interpretation. We will also produce more mappings in similar manner (e.g. as in) for all individual symbols in Python and their combinations (statements). Now if we would argue about images of such mappings, we would do so in form of proofs in Reason language. The question would be if subset Pythonic indeed exists can we follow that up from aximos in Reason built/reformulated from "Zen of python" or other motivating set of concepts? In fact, the whole deductive core of the language Reason would be built from "Zen" or PEP8. We will have to proof that each program from Pythonic will consist only from statements for images of which in Reason can be shown to satisfy initial axioms of the model language. Different outcomes are plausible:

Subset of Pythonic programs could be empty. We have not found any programs that would satisfy our axioms in Reason.
It could happen that this set of axioms would turn out to be ambiguous (inconsistent or incomplete). Then our original assumption about existence of Pythonic programs would be wrong.
Alternatively axiomatic "Zen" could be simple enough and so well-chosen that Pythonic set is non-empty. Now the question is will such (consistent, complete) set be of practical value, i.e. can we say that such set of axioms is indeed a formal definition of "pythonic"?

This is a draft of how one can try to approach answering the question in formal manner. I would appreciate recommendations on a more elegant approach for solution to the problem (everything except ignoring it). But at the end it matters to me to see how such set of axioms looks like. Hence it will allow in precise (quantitative) way to ask and try to explain questions like why programs have "pythonic" qualities once written according to following python "dogmas"?

BTW One can built a more sophisticated model of Reason by introducing an equivalent of "human factor" – a software developer of the programs. Then the question would be – can human formally claim the program he rights belongs to "Pythonic" subset?

Best Answer

A formal definition for the term "pythonic" would be largely impossible.

It's as impossible as a definition for "aesthetic" or "convenient" or "delightful".

It can't be less subjective than it is now.

Why not?

Because Python is merely as aesthetic judgement based on the opinions of a fairly large number of people. The GvR points are respected, but do not have the force of law. Many people write code for the Python world, and their various inputs influence other developers. It's a vast social network of people all liking (and disliking) the code they read.

Ultimately I would like to get closer to more logical or mathematical interpretation of the matter

You would do well to start with studying art, aesthetics and philosophy first. Then, after mastering aesthetics and morals, switch to ontology so that you can encode what you learned about truth and beauty. Once you've finished that, you'll have a formal definition of Pythonic along with formal definitions of all the various subjective values that we hold.

axioms ... built/reformulated from "Zen of python"

It's a poem. It's value is entirely aesthetic. What more evidence does one need that Pythonic is a value judgement based on depth of experience?

Type Annotations

Implementations

For starters, static, compile time type-checking ability was added to Python 3 in 2015.

Now, there are multiple third-party libraries that provide an implementations for the new type-checking hooks.

MyPy — data type-checking only (fulfills Python 3 type annotation capability)
PyContracts — same Python 3 type as in MyPy above, plus allows conjunctive value constraint(s), which is like what you are talking about.

MyPy is pretty slick.

It even supports overloaded function parameter constraints, so that a function can have different return value type if it takes different parameter value types, for instance, using @overload decorator.

Examples

If in your example above, 'length' and 'width' values were passed as discrete parameters, like:

def area(length: 'int,>0', width: 'int,>0') -> int:
    pass

then, PyContracts could easily do individual type/value checks.

PyContracts can work with the dictionary you specified too, as-is.

def area(rect: 'dict(str: int)') -> int:
    pass

Problems with PyDBC

Though it was slick for its time, nowadays, the drawbacks I see with PyDBC are:

There is a slight performance hit to running these precondition/postcondition tests. They're dynamic, run time tests. Python 3 type annotations are done using static analysis.
Rewriting code at runtime, for one purpose, in a one-off way, that is scattered throughout your program, can be too brittle to be worth the bargain. Works fine with one use. What if some other technique/tool does that too? One can get into conflicts where the only way to get out of them is to drop one tool or another after depending upon it a long time. Cleaner ways to do this have evolved for Python since PyDBC was invented.
Explicit declarative constructs, like Python function decorators and Python 3 type annotations, are going to be instantly recognizable/understood by any programmer familiar with Python. They won't spot the implicitly invoked functions. Once they are told, they may forget, may copy or rename the primary function and forget the precondition/postcondition sidekicks. Automated tools are going to treat those extra 2 functions as independent, when they intent is that they are not.
The metaclass attribute feature of Python 2 no longer works in Python 3. It is ignored. Instead, metaclass= is specified in class declarations in Python 3. Nowadays, new projects start in Python 3 and Python 2 is legacy.
Python 3 has reworked the type system slightly going from early Python 2 to recent Python 3. A Python 2 metaclass-based solution may not work with Python 3 without rewriting/retesting it.
Metaclasses are not module-wide now, can only be specified per class, and there can only be one metaclass per class. So it is a preciously applied feature of a class.

Unit Testing

To take things farther, into the realm of checking post-conditions, which is appropriate for testing in the fashion of TDD or BDD, one might be better off writing unit tests—particularly if the desire is to test side effects.

TDD unit tests with unittest

Python comes with a unittest package that works fine for verifying external behavior effects of a class are correct.

https://docs.python.org/3/library/unittest.html

It's very handy to use. If you want to test all of your boundary cases (like dimensions<=0), normal case, and any exceptions it supports in the future, it's the right place for it.

BDD testing

There are some third-party programming tools for BDD (behavior-driven design). Which ones are popular/supported will probably change over time.

In my opinion, BDD test scenarios tend to be easier to read/understand. They're readable, possibly even slightly extendable, by non-Python programmers. The step language is pretty simple.

doctest comments/tool

Alternatively, one could include executable examples in the area function's doc string and test it by running doctest—a standard feature of Python for far more than a decade.

https://en.wikipedia.org/wiki/Doctest

By using doctest, tests would be part of the documentation, inline and generated, as both useful examples and convenient tests.

Those are appropriate ways to check that external state/logic of the function is working properly, given fully met preconditions. They tend to offer different side benefits as well.

Decorators

One can also use Python 3 decorators to declare preconditions and post conditions. The @precondition would be checked on entry. The @postcondition would be checked on exit.

This would allow you to enforce design by contract (DBC) with very little code at all.

To illustrate this listing 10, the @require decorator sample function, in this Dr. Dobb's magazine article, which shows how to implement a powerfully declarative, yet fully reusable, precondition-checking decorator in just 10 lines of regular Python code.

http://www.drdobbs.com/web-development/python-24-decorators/184406073

You could write a post condition verification decorator based on this @require example, and name them @precondition and @postcondition.

Just be careful. The example uses eval, and there is no parameter sanity-checking or constraining, so someone might put something. Really awkward. Of course, that's a possibility other places as well, but I feel like I should raise awareness since eval/exec uses should always kept in mind as a concern.

Python 3 includes a library called functools that actually offers 2 capabilities handy for your problem.

https://docs.python.org/3/library/functools.html

It has a decorator that provides a LRU (least recently used) cache for memoization of a decorated function's return values: @functools.lru_cache
It eases writing decorator functions.

On the 1st point, that strikes your need to test the memoization feature; supplied, pretested functionality. Memoization is a very handy efficiency tool. In addition to reusing existing code, using lru_cache decorator is going to make your area function much more transparent.

Anyone would be able to see that there is memoization (results caching) going on, without needing to read all of its source code, just by seeing the lru_cache decorator. They would know it's tested code too, not some embedded, one-off logic.

For the second, if you needed something more robust, complex, or implementation specific than the Dr. Dobb's example, functools may speed your efforts.

Particularly, you should look at the @functools.wraps decorator. It not only saves a couple of lines of code, but makes the metadata more intuitively correct an useful.

Error-Proofing

The following suggestions made above will make the example correct, less error-prone as-is not to mention if modified, easier to read/understand its usage and behavior, well-tested.

Removing the area result-caching from the rect: dict parameter gets rid of calculation/state error. Replacing it with the standard library's @functools.lru_cache decorator has none of the drawbacks and virtually all of the benefits. The performance savings is still there. A function should do one thing, and do it well. Callers could store the value returned by the lru_cache memoized area function in an object if desired. In fact, an object could store it in an instance variable. It could even do so in a property read by a getter, fulfilling the DRY (don't repeat yourself) principle. So nothing good is being lost or precluded by extracting the memoization, making it an extrinsic quality. Separation of concerns is key to designing good, reusable, reliable, testable functions.
For generic handling, like record-processing, a dict (or tuple/obj) makes sense. For something like this, explicit/discrete parameters are more easily understood/tested because they're self-documenting. The new type annotation syntax is simple & efficient for authors to read/change anytime, and tools to verify when developers feel like it.
Docstring with doctest compatible examples and unittest test cases will make sure the function works, and stays working.
Writing @precondition and @postcondition decorators is easy to do and can make the code more readable.