Note however, that being a good C programmer can be harder than being a good python programmer.
Oh how very true ;), but doesn't this statement in itself answer the question. python == easy to write, easy to maintain, fun and featureful.
I see many python developers get into the habit of writing short-term maintainable code and replacing it often long-term. I think this is just because developers get used to python being so simple to rewrite and saying, 'I can fix it later.' This is both a good thing and a bad thing.
Thinking through an implementation doesn't just apply to C, I have put a lot of thought into wine doors, considered many features and would prefer not to rewrite it in the long term. (Although I did rewrite the GUI code and introduce a queue iterator this weekend, glade rocks ;))
If I say it _must_ be written in C win32, perl or bash then immediately developers will consider the issues, ok perl could do a lot of it easily but there are some problems in other areas, bash would be a large amount of work and win32 C would mean lots and lots of code auditing, re-factoring and bug fixing, probably resulting in a 5 year development process to get the application to a point where it is in regular use. These issues may serve to deter a developer from taking on the project with a view to "I'm not getting my hands on that train wreck".
That's just not true at all. While I see python programmers regularly regurgitate this whole 'C is unmaintainable and takes years to write' thing, have you considered what language python is written in? And is it a buggy train wreck? Those new modules you use after a python upgrade, did they take 5 years to write?
This is a bit out of analogy, I know that C can be written in maintainable and clear and clean, however how often is this evident, how often are memory leaks an issue in C/C++ versus python, but when you're talking about downloading files, parsing XML, drawing a GUI, interfacing with the unix system, managing an install queue and the various other tasks which are important to the success of such an application are difficult to achieve in C using a prototype -> develop -> test -> deploy cycle, admittedly there may be some use of win32 applications to interface with the wine environment but I think this is something that for the most part can already be done with regedit, and there is possibly a requirement for other small applications.
And how many dependent libraries would be required for XML/HTTP in C?
The "train wreck" statement is meant to make you consider that many developers, myself included would rather not do this in C because it could very easily end up as a popular Italian dish version of an application.
A C version of this screams complexity, possibly one reason winetools is written in bash. You must understand that I'm not saying C is a bad language, I'm not saying that it is completely unmaintainable, but when the simplicity vs. complexity issue is considered python wins out. I'm new to python, after many years writing C/C++/php/perl and various other bits n bobs. I see it as ideal for this small simple app, I can have a functional application out much sooner than if I was writing it alone in C.
Everybody knows a badly made win32 C program is possibly the worst possible thing imaginable, but there are many examples where well written, maintainable and relatively bug-free applications were written quite quickly in C.
Agreed, however there is always more code and more ongoing development required to maintain a C application over a python app, this is because C is a more in depth language. I write C too btw, and I have done GTK in C, enjoyed it and found it easy to do, however there are some complex issues with for instance dealing with arrays and linked lists in some instances which are far easier in python/perl/php/probably any language beginning with p, except prolog.
I don't have anything against python, and it is a great language to use, but that doesn't mean it's the best possible language to use for every conceivable project. Wine is supposed to be a way to run Win32 programs on UNIX, and not every unix flavour comes with GTK and python. I think people would say Wine has enough run-time dependencies, and there's no strong reason why another one can't be avoided here.
Python and GTK are available for every UNIX flavour, even OSX, regardless of whether it ships with it. Do you know if SCO currently ships with wine? does it ship with python?
The point here is that if someone is willing to install wine, chances are they will have all the libraries required for it on a unix system, and most unix systems come with python and vast majority of them ship with gtk.
I seriously doubt that as far as users are concerned that dependencies would be an issue, the user in general just wants something that works, and they don't care that 4 extra dependancies are required (python, gtk, pygtk, pygtk-glade)
K,