Yet another garbage article on "how to become good at X".
Idioms are indeed important, but TDD won't improve your proficiency (except in that you'll learn a testing framework and be writing more code). Neither will attempting to adhere to a "Functional" style when you've not already learned the important lessons of FP from an actually FP-oriented language. Coding guidelines? Be consistent. Discover the guidelines of the code you're working on and use that. That has nothing to do with python or proficiency.
Performance is probably the last part of proficiency that one has to learn, and arguably the most difficult. A lot of other skills have to come together before one can count "performance" as a point of their proficiency in a language, and most of those skills are really quite language-agnostic. Oh, and if you're focusing on performance but you don't yet know how to properly profile and benchmark, you're not proficient.
If you really want to become a proficient Python programmer (or any other language) try this:
1. Find the documentation
2. Learn how to navigate, search, and read the documentation
3. Find a skilled mentor or some community resource (IRC, mailing-list, website forums, etc)
4. Ask what is considered good code. Read it. Study it.
5. Create a project - little ones, like sorting your MP3 collection or mining your email for statistics.
6. Try to use the lessons learned in the code you've studied when writing your project.
7. lather, rinse, repeat. Chances are, you're not proficient until you're doing it for several hours every day - and even then, you're probably not really "proficient"... yet.
I agree with the thrust of what you're saying here, although:
> TDD won't improve your proficiency
Disagree. Knowing that you need to test your code, and going back and testing your old code gives you a real feel for how to split out code, how to write interfaces, and how to organize your objects - at least in Perl and JS, which are the languages I'm proficient in.
If you know that your routine that'll be accepting an object might be accepting a mocked up object, you're more likely to resist the temptation to get all molesty with its private methods; if you know you'll spend time trying to drive up the code coverage, you'll be more inclined to abstract and not repeat yourself.
Random plug for a book that made me a waaaay better Perl programmer: http://perlmedic.com/
re: Perl Medic... Excellent book. What I learned there has served me very well with Perl, and also helped me with work on some crufty Python as well!
Also, yeah... I should take-back the TDD comment, or at least re-word it. I just get a little knee-jerky when I hear the word TDD mindlessly spouted out as a panacea. TDD works best when combined with other best-practices, and of course, learning how to write tests that help and don't become yet another ball of mud is an art in itself!
I've learned a lot from reading Twisted and the CPython internals. The newer (2008-) code in Twisted is generally very good.
Another strategy is to skim the source code for your dependencies, without worrying about whether the code is good or not. You'll still get a good idea of the scope of the problem the library is solving, and whether it looks like the authors knew what they were doing. You'll have a crude map of the code in your code, useful when you run into bugs later.
When I was new to python I did exactly what you said, and discovered the following facts:
1. Reading a library you are using, even if it's a standard library like smtplib is fun and makes you smarter and your code better.
2. Python is such a joy to read, unlike some other languages.
3. Some libraries (I'll mention smtplib again) are such a mess, and yet reasons 1 + 2 still make it easy for you to learn from them, while also learning what not to do.
Twisted isn't very Pythonic, in that very few Python code-bases grow to have as much code as Twisted does, and the coping mechanisms Twisted has evolved to keep that code manageable wind up looking like Java because that language is also designed to make large projects manageable.
The number of classes and interfaces in Twisted is a bit of a stumbling block, but I've never come across anyone with a better, more "Pythonic" way to express the same ideas or provide the same flexibility. The ABCs introduced in modern Python are inferior to the interfaces Twisted uses, and the most recent PEP I've seen for Futures is but a pale shadow of Twisted's Deferreds.
Idioms are indeed important, but TDD won't improve your proficiency (except in that you'll learn a testing framework and be writing more code). Neither will attempting to adhere to a "Functional" style when you've not already learned the important lessons of FP from an actually FP-oriented language. Coding guidelines? Be consistent. Discover the guidelines of the code you're working on and use that. That has nothing to do with python or proficiency.
Performance is probably the last part of proficiency that one has to learn, and arguably the most difficult. A lot of other skills have to come together before one can count "performance" as a point of their proficiency in a language, and most of those skills are really quite language-agnostic. Oh, and if you're focusing on performance but you don't yet know how to properly profile and benchmark, you're not proficient.
If you really want to become a proficient Python programmer (or any other language) try this:
1. Find the documentation
2. Learn how to navigate, search, and read the documentation
3. Find a skilled mentor or some community resource (IRC, mailing-list, website forums, etc)
4. Ask what is considered good code. Read it. Study it.
5. Create a project - little ones, like sorting your MP3 collection or mining your email for statistics.
6. Try to use the lessons learned in the code you've studied when writing your project.
7. lather, rinse, repeat. Chances are, you're not proficient until you're doing it for several hours every day - and even then, you're probably not really "proficient"... yet.
/rant off