[Python-Dev] stats.py (was 'summing a bunch of numbers ')
Guido van Rossum
Mon, 21 Apr 2003 20:57:42 -0400
> > > We can't go and incorporate every useful
> > > 3rd party package into the core
> Why not?
Because of the costs associated with code in the core:
- Once it's in the core, you can't take it away; if the original
maintainer goes away, we have to somehow keep up maintenance;
there's no such thing as maintenance-free code. E.g. see the pain
it takes to get SRE bugs fixed now that Effbot is too busy.
- The core needs to build and run on a large variety of platforms.
Some 3rd party package authors don't have that goal, and maintain
their solution for one or two platforms only. But what's in the
core should (unless it is *inherently* platform specific) run on all
platforms. The extra portability work must be done by *someone*.
- If it's actively maintained by the original author(s), their release
cycle may not coincide with Python's; given Python's size, Python
releases are typically less frequent than other package releases.
There's not much point in having an outdated version of something in
the core. E.g. see the painful situation with the xml package and
the PyXML distribution. This is one reason why win32all is still
- Coding standards. I don't care what naming and other coding
conventions are used in a 3rd party package, but there are certain
minimum standards for core code (see PEP 7 and 8). This is another
reason why win32al is still separately maintained.
- Documentation style. For core packages it is expected that their
documentation is maintained in our special LaTeX dialect.
- At some point the download size simply gets too big, and we have to
break things up again. This has happened to Emacs, for example.
- For some areas (I'm not saying that this is the case for the stats
package, for all I know it's "best of breed") there is considerable
disagreement among (potential and existing) users which package
providing certain functionality is "right". E.g. Twisted vs. Zope.
We can't put every approach in the core, but putting one package in
the core may damage the viability of another, possibly better (for
some users) solution. To some extent this has happened with GUI
toolkits: the presence of Tkinter in the core makes it harder for
other GUI toolkits to compete (leaving aside whether Tkinter is
better or not -- it's just not a level playing field).
Feel free to enter this in the FAQ; I've got a feeling this is a
generally useful response. ;-)
--Guido van Rossum (home page: http://www.python.org/~guido/)