Mario Figueiredo marfig at
Tue Jan 20 01:35:29 CET 2015

In article <mailman.17862.1421705173.18130.python-list at>, 
zacharygilmartin at says...
> Why aren't there trees in the python standard library?

I don't know much about python development process and strategies, but I 
suspect it shouldn't be much different from any other language I know 
of. So here's my tentative answer:

Once general purpose programming languages become established, the STL 
maintainers tend to greatly decrease additions to the standard library, 
except when this is required to support new language features. Most of 
development on the STL shifts to code maintenance in order to improve 
the quality of the code (usually to address memory usage and performance 
concerns) and solve any existing bugs on the STL.

Instead the language maintainers start to rely on third-party libraries 
as a continuation of the effort to extend the programming language 
further. Any new additions to the STL are carefully pondered. The reason 
is twofold:

1) Just like with the matter of data structures, many additions are 
implementation-contentious. Trees, for instance, can be implemented in 
any number of ways, some with an emphasis on performance, others on 
memory usage. The decision of which implementation to choose isn't easy. 
And if users can already choose different types of implementations from 
the external libraries, then this is is probably motivation enough to 
delay the decision for another day.

2) A standard library should focus first and foremost on support of the 
language features. If for some reason this takes time away from adding 
new entries into the STL, that's fine.

There's also the problem of how one should look at a standard library. 
Some maintainers don't look very well at the idea of a monolithic 
approach, while others, like Guido, like to think of a "batteries-
included" programming language, indicating a desire to build a large 
STL. And this is why perhaps your question arises. But "batteries 
included" doesn't mean build a "Total Library". That would be a vain 
attempt for any general purpose language.

More information about the Python-list mailing list