18 comments

[ 3.5 ms ] story [ 60.2 ms ] thread
Have read this myself, and can confirm it's pretty solid stuff. Also, the writing style has an admirably high information density. He cuts to the chase.
When is it a good idea to use @property? It's tempting to apply to almost every 0-ary method, even if it computes something expensive that isn't not worth memoizing and tying to self's lifetime.
If it is a 0-ary method AND does not mutate the state of its instance.
... and if it's not likely to cause performance issues.
And if you're not going to leak an AttributeError from any code in your method, else hasattr will return False.

    Can't afford the book?
    Not a problem

    If your financial situation doesn't afford you the
    opportunity to purchase the book, email me at
    jeff@jeffknupp.com and I'll happily send you a free
    copy. Just be sure to note in your email which version
    you'd like.
See, now that's just classy. I was on the fence about whether or not to buy before seeing that and somehow it tipped the balance for me. No idea what it's doing on the whole for your conversion rate, but it definitely helped here!
In the example he gives, wouldn't it be more simple (if not idiomatic) to write

    print(index, element)
instead of

    print ('{} {}'.format(index, element))  ?
Why use string formatting for something so simple, especially when Python inserts spaces in between multiple items automatically?
I think it's because you're likely to change formatting as your code evolve.
I agree on both points. Therefore, when the time comes, change it. No need to over design if unnecessary. The reason I agree to using .format is because it is more expressive in describing the output vs inference in using print.
You could use .format() to support both Python 2 and 3 from the same source
This marketing site fails to answer the most important question: What's the value proposition? Why should I care writing "Pythonic" code?
I think that might fall under "If you need to ask, you're not the intended audience".
He expects you to already be convinced that writing idiomatic Python is what you want to do. If you're not, here are some arguments:

1. The idioms are generally the most elegant way of using the language, so if you use them, it means that you will use the language in the most efficient manner ("with" statement for file handling is one example);

2. It's easier for other people to work with your code;

3. You feel good knowing you're doing the right thing.

Good points, I'd like to add:

4. Idiomatic code receives more attention from the Python core developers and might become faster in the future (for free!).

I bought it, I write quite a lot of Python (I use it for automation, deployment etc) but I sometimes feel like I'm fighting the language.

Also the "don't write this" looked awfully familiar.

I've had these two books for a while. He updates them rather regularly and they contain exactly what the author states. Python isn't supposed to have TIMTOWTDI, but when you start getting in the weeds you figure out bad ways to do common things. This book can help you recover from bad habits.
I’m confused... I bought this in January 2013. This doesn’t mention an update... is it that it’s now a book that’s new?