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

[Magnus Lycka]

> I believe, if I understand you correctly, that something is Pythonic 
> when it has a sense of quality, simplicity, clarity and elegance about it.

I guess it's a bit like sitting down in your favourite armchair
just to realize that this isn't actually your chair. It's been 
replaced by something that feels different. You'll probably have
to think a bit before you can tell how it's different, but you 
might well have felt the difference immediately--or it might be
something just just felt strange after some time, becoming more and
more bothersome with time.

For a long time Python programmer, most new Python libraries have
a lot of commonalities with things she's already done, and it's
usually quick to find her way in them, and understand the concepts.
Of course, they might cover a problem domain which is new and 
different, but anyway, they feel familiar.

Some don't, and I guess they tend to get the label unpythonic.
They might be very useful, but they don't fit so well into the
Python world. One concrete example in Zope 2 is extension classes,
which was a foundation for the persistence mechanism in ZODB.
While useful, they did magic thing under the hood which for instance
made pyChecker puke. Zope also did magic things in the imports
that were a bit bewildering. 

Python is a bit different in this respect from many other programming
languages, such as Perl--where the motto is "there's more than one way
to do it", or Tcl--which has such a rudimentary syntax that it's 
common practice to more or less create a new syntax for every new 
problem domain.

This is also supported by the fact that you get a lot more Google hits
for "Pythonic programming" than you get for "Javaesque programming" or
"Perlish programming" or "Tclish Programming" etc. Python code seems
to be distinctive in having a particular character, and the Python
community seems to have a lot less Cowboy Programmers than most other
languages. If you hate to conform to standards, you won't like Python
I guess. Maybe the significant indentation serves as a kind of EQ test?

I think this feeling of quickly feeling at home in new code is an
important part of Python's usefulness. See e.g. Eric Raymond's
LJ article: http://www2.linuxjournal.com/article/3882

"... That was my first surprise. My second came a couple of hours into the project, when I noticed (allowing for pauses needed to look up new features in Programming Python) I was generating working code nearly as fast as I could type. When I realized this, I was quite startled. An important measure of effort in coding is the frequency with which you write something that doesn't actually match your mental representation of the problem, and have to backtrack on realizing that what you just typed won't actually tell the language to do what you're thinking. An important measure of good language design is how rapidly the percentage of missteps of this kind falls as you gain experience with the language.

When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!

This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process."

What Eric talks about here is to a large degree an aspect of the core
language, but this useful feeling of familarity gets even bigger if
libraries and frameworks build on established Python concepts and
habits.

I.e. if you wrap C++ iterators, a Python programmer will want to be
able to write:

for x in x_list:
    do_something(x)

For someone who is thinking in C++, it will be natural to expose
the C++ iterators more thinly, and you'll probably end up writing:

pos = x_list.first()
while pos != x_list.end():
    x = pos.deref()
    do_something(x)
    pos.incr()

The programmer who writes this wrapper will probably complain that
Python lacks "real" for loops and ++ operator. The python programmer
who uses this code won't be very happy, and if he makes a pos.incr()
followed by pos.deref() without checking x_list.end() first, he'll
probably get a segmentation error, which is very unpythonic!

The C++ programmer will complain that the Python programmer is stupid
not to check his boundry conditions, and the Python programmer will 
complain that the C++ programmer is stupid who forces him to bother
with details that have nothing to do with the problem domain...

Other examples of unpythonic things brought from people used to
other languages is to worry about typing in a way that just makes
the code more brittle and less usable.

-- 
Magnus Lycka, Thinkware AB
http://www.thinkware.se/  mailto:magnus at thinkware.se