[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