The python community thrives on discussion. Like really, long, heated discussion. Python is by far the cleanest and most artistic language I have ever seen, and the CPython API is equally as impressive. I’ve actually become very entertained the last several months just by reading discussions about language design, most prominently about discussions regarding the GIL. Sometimes the discussions get pretty heavey, and a lot of times participants get a little fired up. Recently I wrote the following response to this blog post, which you may have read on planet python:
There are two opposing forces here, and you can see them just as well in discussions about the GIL.
The first one is the progressive and more open-source oriented mentality that promote better features and cleaner code. These are the people that hang out on IRC, write really cool extensions, and generally have a very academic and intimate knowledge of the python api.
The second one is a more practically goal and business oriented mentality, that promotes stability and proliferation. These people are more often than not getting paid to write the specific chunk of code in which they choose to discuss, and are blessed with not having to worry about the imperfections of the code as long as they make their deadlines.
There will always be a compromise between these two forces. I like to fall into the first category, preferring to take my time with unit tests and a detailed understanding of my code, because I do not enjoy going back and fixing concepts that should have been completed the first time. But, I don’t get paid for my clean concepts, I get paid to meet deadlines and to be able to maintain the code I’ve written.
Your code doesn’t need to be perfect to have fun AND make money, and your language doesn’t either. But, you also need to have that bleeding edge branch to keep the spirit of the craft alive. I’ve never used ruby, and I’ll never write java again, but one thing I can say about the python community is that there is a very large number of people that are involved in discussions across the spectrum, and this is nothing but healthy for the language, just like bleeding edge 3.0 releases and easily maintainable 2.5.1 XServe releases.
Oh yeah, and in the words of the BDFL, “CODE TALKS.” This applies to both groups.