[EuroPython] What the heck does "pythonic" mean?
faassen at infrae.com
Tue Apr 12 20:06:29 CEST 2005
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"
> 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:
return "Foo", "Bar"
foo, bar = something()
whereas this is not:
l = 
foo = l
bar = l
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
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
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.
More information about the EuroPython