Many developers are always willing to reinvent the wheel, even though they would be much more productive getting used to a set of libraries. The problem is, Python allows people to reinvent the wheel easily. I'd rather stick to libraries that already exist, and only do all the work myself if the existing wheels really cannot make my car run fast.

Dude, you got it so wrong I don't know where to begin with.

Could you please do some reflection of free market economics, democracy, opensource, choices, voices and voting, consolidation and innovation, responsible netzizen behavior and about the price of freedom which is eternal vigilance.

No I'm not american and you're not looking over the edge of your teaspoon, please wakeup!

Of course, the question is whether you have 8 ways to open the same trunk, or 8 totally different cars. The analogy is pretty broke in any case, but if you assume the latter, it'd be pretty silly to tell a sports car driver that from now on everyone must drive a pickup truck.

In general though, I've heard of wxPython, and none of the rest. I've also seen a lot of apps and job opening's using wxPython, so I'd generally assume it to be "the" GUI toolkit for Python. If it didn't work out right for me though, I'd be happy knowing I could switch to a toolkit that does.

Ah yes, but why not just get everyone to work on the same projects? That goes back to the car analogy perhaps. Would you proclaim to the performance obsessed that they should try and fix the pickup so it can perform like a sports car? Of course not, the fundamental architecture and design is different. Same situation exists in toolsets, even if the superficial outcome is the same, or in the analogy... you travel on the same road.

"Of course, the question is whether you have 8 ways to open the same trunk, or 8 totally different cars."

Did you read the quote in it's original context?

"it'd be pretty silly to tell a sports car driver that from now on everyone must drive a pickup truck."

Nobody's doing that, of course. It's the exact opposite that's a real problem in today's Python universe. When someone asks for a BMW-style sedan, the replies from happy Mercedes and Lexus owners drown under replies from people with old bikes, home-built Segways, Trabants, formula 1 racers, and 1/8 scale radio-controlled airplanes. Not to mention the guys with a pile of wheels and old WV engines in their backyard who claims that everyone else is completely missing the point, and the guy who's been thinking of buying a pair of pneumatic stilts.

Assuming that there exist BMWs for every problem of course, and silver bullets for that case.

Afaik there's not (yet) a GUI BMW, or a Web Framework Lexus.

And anyway the analogy is broken, because foss economy products are not used, exchanged and valuated the same way as consumer goods.

But like any economy new market niches produces abundance of competitors at first, only to consolidate later.
The biggest consumer benefit happens when a market has reached saturdation point and competing offers weed out the crap from the crop.

Isn't it quite obvious why having a choice is good, altough tiresome?

"And anyway the analogy is broken, because foss economy products are not used, exchanged and valuated the same way as consumer goods."

That's a nice myth.

Fredrik, trying to defuse an argument by lala-i-dont-hear-you logic?

Software is information, and thus easy to "produce" but hard to come by. Consumer goods price is largly fixed by production cost and not by design.

In the consumer goods market a large part of the customer decision is driven by the upfront price he has to pay for the good. Practically all other considerations like quality, endurance, usability take a backseat at that (if it wasn't like this, could you then please explain to me how the pleathora of extremely craphish and unusable products manages to be present at high volume everywhere in shopfronts and outlets?)

However lacking an upfront price to pay the consumer establishes other metrics by which to judge a product. Presumably now the backseater criteria come to the front, and things like quality and usability dictate the decision.

Of course they do not if you refuse to make a choice...

So you'd like to see the choice beening shifted to some BDFL. His choice can be as wrong as any other s choice.

And by refusing dictate of choice a minor evil of choice abundance is introduced which forces the market to make a choice. On general principle I believe that the foss economy makes better choices then single individuals.

Having worked with all the toolkits, I can tell you, no-one is perfect: when I am writing software in python I am competing against similar software written in Java, C#, Perl, Ruby and C++. This is software that targets the end user.

Python does NOT have a toolkit that: looks good everywhere, works everywhere, offers all the basic widgets and the user does not need to download 20MB of deps (or even install a new distribution (pygtk)). Python is portable, but its toolkits are not :(

The solution I proposed was a wrapper API. Should you want the pythonwin API? Fine. But the programmer should be using ONE API for doing his widgets. Whether this gets rendered with Win32, QT, GTK, wx or Tkinter would be up to the user.

There is no cooperation in this direction without explicit proclamation because every toolkit writer is looking after their own interests.

Unfortunately Python is open-source and isn't subjected to economy forces. Python has been around for over 10 years and many algorithms are still available and accessible. I would dare to bet that each problem (a person might face with Python) has already been solved at least 10 or 20 different ways over the years. If I was a newbie at Python and need to solve 1 item of my 100 items for my program TODAY, which of those 20 do I choose? After 5 days of arduous choosing, I might just sneak back into C++ and C. At least there, only a handful of ways of doing something is available.... usually, there is only 1. And hurray for that.

"Isn't it quite obvious why having a choice is good, altough tiresome?"
that is the point... we are overwhelmed with tiresomeness. When you pile on tons of little tiresomeness, it becomes one big one. The scariest tyranies are the little ones that creep up at you.

Could this be the reason why managers and decision makers are turned off by Python? I already know developers absolutely adore it. I'm just being frank: but a handful of developers in a corporation of multi-thousands just don't make an impact unless they are backed by decision makers.

Joao Marcus' comment above hit it right on the nose succinctly. The net effect of "reinventing the wheel" is that we are much less productive. There is too much of reinventing in the Python community. Honestly, sometimes I feel more productive with C++.

C++ in the Microsoft arena:
- editing/debugging : Visual Studio
- Graphical interfaces: MFC or .NET Forms
- Platform services: Win32
- What I have to get done today: me. Now I can get on with my life

"lala-i-dont-hear-you"

I hear you. But it's also quite clear that you don't hear what I'm saying -- which is that you're pretty ignorant if you think that Python is competing in some kind of isolated "foss economy" where human efforts have no cost, and where the target audience is a special kind of "foss consumers" for which the usual rules don't apply. It may work that way in your corner of the Python universe, but it sure doesn't work that way all over the place.

(heck, why do you think it was so important to some people to get a python.org site with a more "corporate" look?)

And no, I'm not asking for one true framework/toolkit/space potato picked by a BDFL. Where have I ever said that?

Hoang, nice write up. Believe me, life was simpler when Python was younger and there were less libraries around.

Fredrik, a lot of old timers who contributed to the Standard Python Libraries pre Python 2.1 wrote nice usable libraries. You know, libraries that can be used without subclassing? I reckon these folks can tag new libraries with "old-fogey-style-libraries" and I'd use new ones by these guys with no hesitation. A lot of the newer libraries are simply hard to use from the command-line. Take timeit, for example, it's not really usable within the REPL because of the way exec is used, instead of apply.

Moaning about the abundance of crappy choices is the wrong thing to do. It is deconstructive critisism which projects one solution to the problem, that of reducing choices, which would be wrong.

An abundance of crappy choices is one phase of the lifetime cycle of in a foss product economy niche (like GUI tookits, operating systems etc.)

In the best of cases this phase will not degenerate to a permant situation, in some cases however it does (almost at least).

So you want to do something about the deadlock of the abundance of crappy choices phase? Simple as introducing better choices behind which you can rally the dispaired users behind. (in some special cases this is not true, and the deadhgrip of the phase has different origins)

Fredrik you made an applaudable efford at that with elementtree. Part of why people dispair at xml is the crap of api's the get to handle them. ElementTree helps witht that enormously. That it will get introduced into the standard library is an enormous win for the xml processing capabilites of python, and it has shook up the traditional python xml communities deathgrip.

Why of all people do you moan about an abundance of crappy choices when you could promote the correct behavior, that of creating better choices?

By the way, when I talk about reinventing the wheel, I am NOT criticizing the great guys that are always building nice nice Python libraries and utilities. One single choice is a bad thing, a bazillion of half-baked choices is also a bad thing. There has to be a balance!