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 _______________________________________________ EuroPython mailing list EuroPython@python.org http://mail.python.org/mailman/listinfo/europython
