[Python-Dev] stats.py (was 'summing a bunch of numbers ')

[Guido van Rossum]

[Guido]
> > > We can't go and incorporate every useful
> > > 3rd party package into the core

[Raymond]
> 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
  separately maintained.

- 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/)