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:
Python 3.0: “What’s the Point”
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.
This is off-topic, but I couldn’t find another way to contact you.
It’s about pyrtmidi. I have a patch that makes it compile better. My system is windows XP 32 bit, with the latest MinGW32 and Visual Studio Express 2005 installed.
With Python2.5, there was no way to compile pyrtmidi. python2.5 was compiled with Visual Studio 2003, which generates incompatible object files from VCExpress 2005. Mingw32 nominally generates compatible object files, but I ran into this bug: http://www.gamedev.net/community/forums/topic.asp?topic_id=167094
Python2.6 is compiled with Visual Studio 2008. Also incompatible with VCExpress 2005, but compatible with mingw32. So I was able to compile it.
But there’s another catch: I haven’t a clue where -lmultithreaded comes from, and neither does mingw. So I removed that library. And distutils didn’t like your syntax for including winmm.lib, so I changed that. Here is the full patch:
$ svn diff pyrtmidi/setup.py
— pyrtmidi/setup.py (revision 7)
+++ pyrtmidi/setup.py (working copy)
@@ -45,7 +45,7 @@
elif OSNAME == ‘Windows’:
define_macros = [(‘__WINDOWS_MM__’, ”)]
– libraries = [‘winmm.lib’, ‘multithreaded’]
+ libraries = [‘C:Program FilesMicrosoft Platform SDK for Windows Server 2003 R2Libwinmm.lib’, ‘winmm’]
elif OSNAME == ‘Irix’:
define_macros = [(‘__IRIX_MD__’, ”)]
libraries = [‘pthread’, ‘md’]
My email is at the top of the source files and on my Trac site.
Thanks for the patch! Compiling on windows is always a pain in the butt. Let me know how it the module works for you.
Interesting story as for me. I’d like to read a bit more about this matter. Thnx for giving this material.
Asian escorts London