Oh no, not another!
I DISagree with you, and most of the people that have made comments here. I do not think that throwing vast amounts of resources on improving Python Web programming is going to do much more than make it adequate compared to the vast competition out there.
I think we could carve out a better niche for Python by making it the preferred language for scripting applications. When software suppliers don't just do the equivalent of packaging up their software for COM, but are actually delivering functionality by extending their core application using Python. For this to happen we need to focus more on things like KDE/OpenOffice/Gnome/Mozilla/... support.
I am not advocating abandoning WEB tools development in Python, I'm just observing that there are a lot of competitors there and whilst it is very important to show that Python can work there too, I don't think we can ever become the preferred language for web programming.
"I think we could carve out a better niche for Python by making it the preferred language for scripting applications."
I agree that Python applications are a valuable space, even as stand alone applications lose share to web applications.
If you meant embedding Python in applications then look to LUA's successes.
If you meant applications then look at the cross platform problems with wxWindows (Microsoft-specific), Qt (licensing issues), GTK (unMicrosoft-specific), and so on. Similar issues didn't stop Java (AWT's, Swing, and the unSun solutions). Or maybe they did, Java applications are novelties, OpenOffice and Eclipse are blimps.
My personal hope is that Parrot will be uncomplicated, fast, scalable, and very friendly to Python, even on Apache. Python on Parrot may attract those with the skills and mindset necessary to implement the desired Python modules.# anonymous
I think what may be meant by "scripting applications", especially in the context of the excellent work going on with things like PyQt and PyKDE (and I imagine that PyGtk is pretty interesting too), is actually writing KDE and GNOME applications from scratch in Python instead of getting overexcited by some supposed "need for speed" that C and C++ offer and then finding out what kind of wheel reinvention has to go on to support things which Python already does very well.
But I have to take issue with the Qt licence jibe - the GPL should surely be good enough for open source applications, and if you're in the business of writing closed source commercial software for sale, but you can't make the money back to pay the licensing fees for Qt, perhaps you ought to consider another business model.
(As for Parrot, if it has finally moved off defining bizarre Perl 6 semantics as virtual machine instructions, perhaps it has a chance after all. Otherwise, I'm not holding out much hope for it, I'm afraid.)# Paul Boddie
The posts in this thread indicate that people understand the issues involved, what is required to address the issues, and some are moving forward as I type this post. Instead of helping I will continue typing...
I should mention that these are all personal choices, for personal reasons, for personal projects. I'm not aware of any available Python GUI wages.
With that in mind: I choose to avoid writing KDE or GNOME specific applications. I don't keep up, I'm tired of it, I don't care if D-BUS wins or loses. Like Debian, GNOME seems to need more bizarre life and less dusty dust. KDE needs more speed. I prefer the GPL but will put up with the Python license. I suspect OpenOffice is a dead end but would be happy to be wrong. If the first post had mentioned Firefox instead of Mozilla I may have been more enthusiastic. Is it easier to embed Python or Lua? I don't know but would guess Lua wins (given its footprint and popularity). Extending applications externally begins to look like web services, which begins to look like the original subject. :)
"if you're in the business of writing closed source commercial software for sale, but you can't make the money back to pay the licensing fees for Qt, perhaps you ought to consider another business model"
Sure, the GPL creates similar conflicts for profit motives. I wrote
"If you meant applications then look at the cross platform problems with wxWindows (Microsoft-specific), Qt (licensing issues), GTK (unMicrosoft-specific), and so on."
I was thinking of the market confusion caused by TrollTech's licenses, and the various stances and rhetoric spewed over the years. Not my confusion, the markets. Qt license threads are not new.
I choose PyGTK because I like the GPL and GTK and don't care if Microsoft users have to jump through hoops. But my personal choices weren't the point of the quoted statement. The point was that there is not a substantial Python answer to the GUI question when the multiplatform planet is asking (commercial, anti-fascist, and all the rest). The planet sized version of the GUI question begins to look like the web version of the original subject too, and other languages have better answers. My hope is that a personal project might wag the long, killer app tail and that perhaps others will react by cleaning up the messes. If not, at least I am enjoying PyGTK (except for the Menu parent/tearable/popup breeding headaches).
While not caring about a solution for others, including the newbies is certainly a valid choice that choice also surrenders the benefit of network effects, the fun of being able to say "Python is a great language, fast, easy, productive, and goes 'ping'" and not have to conditionalize with "as long as you are smarter than me, have time to learn trivia, and can afford it".
As for Parrot...
I first became nervous when Ruby brought up Visual Basic compatibility. Then Dan disappeared. Maybe Parrot is a dead end. Sadly I think the Python VM is too. So something needs to come along, if not Parrot. Not that I care all that much; I hold my personal language choices close but am prepared to release them at any moment.
Under wages PHP is much easier to pitch. :)# anonymous
<quote>If you meant applications then look at the cross platform problems with wxWindows (Microsoft-specific), </quote>
wxWindows is MS-specific, but wxGTK works fine for me under Linux. Either way, wx has generally been my GUI of choice. And, after reading this thread, I'm going to re-think my stance on php. The pages I have created with it are a mess.
BTW, as far as the hosters go, I'd say there are basically 4 levels of python support: 1. python's installed and you can run CGI with it 2. mod_python 3. zope 4. plone
I really should start evangelizing the joys of plone to try to convince more hosts to offer it. Then again, I'm not sure how hard it is to actually keep it running. Having it on my development box at home isn't really the same.
I think we could carve out a better niche for Python by making it the preferred language for scripting applications.
I disagree with you vigorously. Do we want to tread the steps of such language titans as Tcl and Lua? Ha! Scripting doesn't build community and doesn't build participation, and that matters tremendously to an open source project. Scripting isn't bad for the language, it's just not very good. Honestly, I've never usefully scripted any application with Python, and I've only uselessly done it once or twice.
Also, the idea we can dominate that position is silly. Anyone can create a language powerful enough for "scripting". And they do it all the time -- Lua, rep, JavaShell, yada yada. It's stiff competition for a fairly pointless niche.
If you mean gluing together applications, yeah, okay... but that's not even a niche, it's just an idea. And the web has as much to do with that as anything.# Ian Bicking