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

Guido van Rossum guido@python.org
Mon, 21 Apr 2003 20:57:42 -0400

• Previous message: [Python-Dev] stats.py (was 'summing a bunch of numbers ')
• Next message: [Python-Dev] Fwd: summing a bunch of numbers (or "whatevers")
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

• Previous message: [Python-Dev] stats.py (was 'summing a bunch of numbers ')
• Next message: [Python-Dev] Fwd: summing a bunch of numbers (or "whatevers")
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]