[EuroPython] What the heck does "pythonic" mean?

[Martijn Faassen]

Dario Lopez-Kästen wrote:

> I am trying to understand the various, imho, religious subcultures(*) in 
> the Python world, and I need someone to explain what the heck "Pythonic" 
> means.
> 
> How do you judge if something is "pythonic" or not?
> 
> (*) the most prominent example is the "zope is not pythonic" thing that 
> goes around a lot.
> 
> As reference, I have a strong background in the Mac-vs-Pc wars since 
> before 1990, so I know a religious subculture when I see one ;-)

Others already pointed you to 'import this'.

"Pythonic" is vague, but not necessarily that much more vague than words 
like "intelligence" or "life", which, when you try to actually define 
them, tend to be slippery.

Over time, a lot of idioms and ideas arose in the Python community about 
what the right way to use Python is, and also what would be a wrong way. 
Idioms frequently cannot be ported straight from another language, as 
they look odd or cumbersome. Frameworks should also not get in the way 
of writing Python code.

So, this, for instance, is a Pythonic way of getting multiple return 
values from function:

   def something():
       return "Foo", "Bar"

   foo, bar = something()

whereas this is not:

   def something(l):
       l.append("Foo", "Bar")

   l = []
   something(l)
   foo = l[0]
   bar = l[1]

Someone coming from a language like C or C++ might however have designed 
  something like the latter.

Pythonic is to use the Python constructs and datastructures with clean, 
readable idioms. Pythonic is to exploit dynamic typing, and definitely 
not introducing static-type style verbosity into the picture where not 
needed. To be Pythonic is to avoid surprising experienced Python 
programmers with unfamiliar ways to accomplish a task.

When you get to the larger scale, to libraries and frameworks, it gets 
more contentious whether something is Pythonic or not. APIs of Python 
libraries tend to be smaller and more lightweight than those of Java 
libraries doing the same thing. If you run into a Python library which 
has a heavy-weight, overelaborate API, you tend to consider it not very 
"Pythonic".

A Python-based framework can be considered Pythonic if it doesn't try to 
reinvent the wheel too much. It should follow conventions (as far as we 
have them) on package naming, module naming, class and method naming, 
and the like. Preferably it doesn't introduce too many of its own new 
ways of doing things and tries to use as much as possible the Python 
style of doing it, as far as they exist.

Of course the problem is that frameworks, being frameworks, almost 
*inevitably* try to introduce patterns and ways of doing things that may 
not be familiar if you're used to smaller applications. That's how you 
exploit the power of a framework. Zope definitely introduces a lot of 
particular ways of doing things that you don't run into so often 
elsewhere. Acquisition is an example.

To be Pythonic for a framework is difficult. The notion of what is cool, 
idiomatic, good Python code has evolved quite significantly over the 
years, and a framework like Zope 2 definitely shows its age there.

For instance, in recent years there has been a movement towards 
standardizing package and module structure in Python: packages and 
modules should be brief, lowercase, singular, often in some namespace 
package, __init__.py shouldn't have many side effects, etc. Newer 
codebases like Twisted, Zope 3 and PyPy tend to follow this pattern, 
whereas older codebases like Zope 2 don't at all.

Obviously, using new language features like sets and datetimes are now 
considered Pythonic, but Zope 2 doesn't use sets (instead dictionaries 
are used, and it introduces its own BTreeSet concept), and has its own 
DateTime object. So it's not Pythonic there, but through no fault of its 
own.

For a framework, to be Pythonic, I suspect that learning curve for a 
Python programmer plays an important role. A less powerful framework 
that is easy to pick up for a Python programmer may be considered more 
Pythonic than a far more powerful system that takes more of a time 
investment. Whether it's worth it to learn the more powerful system 
depends, as always, on the exact circumstances and requirements.

Regards,

Martijn