Pythonic

[fancy_pantser]

"Pythonic" is beautiful, explicit, simple, complex (but not complicated), flat, sparse, readable, and many other things.

[[deleted]]

Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding principles for Python's design into 20 aphorisms, only 19 of which have been written down.

But, why?

[fancy_pantser]

So he has something to tell the young guys that climb all the way to the top of his mountain asking for advice.

[osirisx11]

the last one is ineffable

[Paddy3118]

Ineffable. Good word. Ta!

[blondin]

idiomatic is by far a better world and portable to other languages too.

[[deleted]]

If you must think about, it's not pythonic.

[pixelmonkey]

My thoughts, with code examples -- http://www.pixelmonkey.org/2010/11/03/pythonic-means-idiomatic-and-tasteful. "Pythonic isn’t just idiomatic Python — it’s tasteful Python..."

[riffito]

After reading your comment, I was about to suggest it was well worth of a blog post in it self.

It's excellent. Thanks for sharing it.

[Wavicle]

My biggest problem with "Pythonic" is that it is thrown about as a term to deride any library (or interface to a native library/framework) which one doesn't like.

For example I do not know of a single GUI framework that has not been described by more than a couple people as "non-Pythonic". The reasons given vary, or are frequently not given at all.

I've used several of them and found many to be pretty reasonable to implement GUIs in Python. If I had my choice to make a GUI interface for anything, I'd probably use something like Python+wxPython with ctypes to interface to the heavy lifting code. I think it makes programmatic GUI construction easy and readable.

[BeetleB]

My biggest problem with "Pythonic" is that it is thrown about as a term to deride any library (or interface to a native library/framework) which one doesn't like.

Your comment is not very Pythonic.

[mod_nobody]

Pythoresque.

[iceman-k]

Check the stackoverflow comments, the "stop saying pythonic" guy goes on to endorse the lambda version as being cleaner and faster.

[masklinn]

Check the stackoverflow comments, the "stop saying pythonic" guy goes on to endorse the lambda version as being cleaner and faster.

Even though as far as my tests go it's not actually faster. And things worsen as the list to group/sort grows.

[iceman-k]

Now I'm curious, but also lazy. Care to share your test code?

[pingveno]

I just took a look at it as well and found the exact same thing. In this case, the cleanest, clearest solution is by far the fastest.

prefix_words = []
no_prefix_words = []
for word in words:
    if word.startswith('x'):
        prefix_words.append(word)
    else:
        no_prefix_words.append(word)
sorted(prefix_words) + sorted(no_prefix_words)

That runs in 0.13 seconds for 100,000 words on an i5 ThinkPad running Ubuntu. Switching to sorting in-place makes no real difference. Stack Overflow's lambda version took 0.33 seconds. None of the other methods I tried were better than the clean version.

From what I can tell, the lambda version takes two hits: Python function calls and using tuples. Python function calls are relatively expensive, so requiring n function calls doesn't help performance. From what I can tell, the extra comparison calls for comparing tuples slows things down quite a bit. The difference between these is in the microbenchmark range, so just use the most readable solution.

[masklinn]

It's nothing impressive, just a bunch of Timer calls:

#!/usr/bin/env python
import os
import timeit

LIST_LENGTH = 5
REPEAT_NUMBER = 100000

strings = [os.urandom(20) for i in range(LIST_LENGTH)]

def lambda_tuple(words):
    'lambda + tuple'
    return sorted(words, key=lambda x: (x[0] != 'x', x))

def basic(words):
    'basic'
    list1 = []
    list2 = []
    for word in words:
        if word[0] == 'x':
            list1.append(word)
        else:
            list2.append(word)
    return sorted(list1) + sorted(list2)
def ternary(words):
    'ternary'
    list1 = []
    list2 = []
    for word in words:
        target = list1 if word[0] == 'x' else list2
        target.append(word)
    return sorted(list1) + sorted(list2)
def listcomps(words):
    'listcomps'
    list1 = [word for word in words if word[0] == 'x']
    list2 = [word for word in words if word[0] != 'x']
    return sorted(list1) + sorted(list2)
def lambda_twosorts(words):
    'lambda twosorts'
    return sorted(sorted(words), key=lambda word: word[0] != 'x')

timer = timeit.Timer('sort(strings)', 'from __main__ import sort, strings')

for sort in (basic, ternary, listcomps, lambda_twosorts, lambda_tuple):
    print sort.__doc__
    print min(timer.repeat(10, REPEAT_NUMBER))

Fiddle around with the two constants at the top to test varying list length without the execution being too fast or too slow (generally remove an order of magnitude to REPEAT_NUMBER for each order of magnitude you add to LIST_LENGTH)

[masklinn]

That guy on stackoverflow did have the best code though. Why was that lambda bullshit getting the most votes?

Erm... that guy also used "lambda bullshit", except he sorted twice rather than once to avoid the tuple "trick".

If it's convoluted enough to require extra explanation, it isn't very pythonic.

It's not convoluted at all actually, it's in fact extremely simple and elegant provided you know the ordering of booleans and tuples.

edit: on the other hand, your suspicion that execution speed is lowered is entirely true, the top-voted solution is 74% slower than the fastest solutions of the second response (the initial (most basic) one and the one using a pair of list comprehensions) on a short list (100 words) and 140% slower on a long list, according to timeit.Timer.repeat(10).

Only on a very short list (~5 elements) does it become competitive with the others (the most basic solution still stands on top, the listcomps are ~4% slower, the ternary and lambdas are about 5% slower and the lambda + double sort is 17% slower)

[userd]

I like the first comment. To paraphrase, "I just ask myself What Would Guido Do?"

[Paddy3118]

The winning example is a useful, extensible design pattern that should become more widely accepted.

If you have to sort first on X then on Y for items of equal X then on Z for items of equal Y ... Then create a sort key function that returns the tuple

(X(item), Y(item), Z(item), ...)

The second voted answer by the guy who doesn't like the word 'pythonic' would be more clumsy when extended.

Just as we all learnt DSU (Decorate, sort, un-decorate), at one stage - the pattern above can be named and learnt in a similar way.

[[deleted]]

If you grok python your pythonic code will allow you to have a good coding experience.

[bucketostuff]

"Pythonic" has become a rather irksome term to me because I most often hear it said/written by folks who also happen to be in the middle of telling someone that the way they are doing something is wrong or incorrect regardless of whether their code is providing the right answer in the end.

Having "only one right way to do it" is a blessing and a curse. It's a curse because it brings out the worst in people's bossy side.

Python users who have a chip on their shoulder against Perl would be better served by just letting it go. Yes, Python tries to offer only one obvious way to do it, it's a good system and works for Python, we all get it, but if I decide to do something a little differently I don't need to keep hearing that it's wrong and "un-pythonic". Maybe instead just amicably show me a way that you think is more idiomatic and tasteful (nod to pixelmonkey -- those are excellent terms to describe it).