[Python-3000] Limitations of "batteries included"

john.m.camara at comcast.net john.m.camara at comcast.net
Sun Aug 26 19:50:48 CEST 2007


Sorry.  Forgot to change the subject

 -------------- Original message ----------------------
From: john.m.camara at comcast.net
> On 8/25/07, "Guido van Rossum" <guido at python.org> wrote:
> > Take for example GUI packages. Tkinter is far from ideal, but there
> > are many competitors, none of them perfect (not even those packages
> > specifically designed to be platform-neutral). We can't very well
> > include all of the major packages (PyQt, PyGtk, wxPython, anygui) --
> > the release would just bloat tremendously, and getting stable versions
> > of all of these would just be a maintenance nightmare. (I don't know
> > how Linux distros do it, but they tend to have a large group of people
> > *just* devoted to *bundling* stuff, and their release cycles are even
> > slower. I don't think Python should be in that business.)
> 
> Python can't include all the major packages but it is necessary for any 
> language to support a good GUI package in order to be widely adopted 
> by the masses.  Right now this is one of Python's weaknesses that needs 
> to be corrected.  I agree with you that none of the major packages are 
> perfect and at the current slow rate of progress in this area I doubt any 
> of them will be perfect any time soon.  There just doesn't seam like there 
> is enough motivation out there for this issue to self correct itself unlike the 
> situation that is currently go on in the web frameworks where significant 
> progress has been made in the last 2 years.  I think its time to just 
> pronounce a package as it will be good for the community.  My vote would 
> be for wxPython but I'm not someone who truly cares much about GUIs 
> as I much prefer to write the back ends of systems and stay far away from 
> the front ends.
> > 
> > Database wrappers are in the same boat, and IMO the approach of
> > separately downloadable 3rd party wrappers (sometimes multiple
> > competing wrappers for the same database) has served the users well.
> 
> I agree with you at this point in time but SQLAlchemy is something special 
> and will likely be worthy to be part of the std library in 18-24 months if the 
> current rate of development continues.  In my opinion, it's Python's new 
> killer library and I expect it will be given a significant amount of positive 
> press soon and will help Python's user base grow.
> 
> > 
> > Would anyone seriously consider including something like Django,
> > TurboGears or Pylons in a Python release? I hope not -- these all
> > evolve at a rate about 10x that of Python, and the version included
> > with a core distribution would be out of date (and a nuisance to
> > replace) within months of the core release.
> 
> At this point in time none of the web frameworks are worthy to be included 
> in the standard library.  I believe the community has been doing a good 
> job in this area with great progress being made in the last few years.  What 
> we need in the standard library are some additional low level libraries/api 
> like WSGI.  For example libraries for authentication/authorization, a web 
> services bus to manage WSGI services (to provide start, stop, reload, 
> events, scheduler, etc), and a new configuration system so that higher 
> level frameworks can seamlessly work together.
> 
> John



More information about the Python-3000 mailing list