No trees in the stdlib?

[Lie Ryan]

João Valverde wrote:
> alex23 wrote:
>> João Valverde <backu... at netcabo.pt> wrote:
>>  
>>> Currently I don't have a strong need for this.
>>>     
>>
>> And clearly neither has anyone else, hence the absence from the
>> stdlib. As others have pointed out, there are alternative approaches,
>> and plenty of recipes on ActiveState, which seem to have scratched
>> whatever itch there is for the data structure you're advocating.
>>   
> 
> Propose such alternative then. There are none that offer the same
> performance. At best they're workarounds.
> 
> I don't care about recipes. That's called research.
> 
> If people don't find it to be useful, that's fine. Surprising, but fine.

Python devs, based on my observation, tend to choose a data structure
based on the interface and not its implementation. Binary Sorted Tree is
an implementation, its interface can be a sorted dict (sorted key-value
mapping) or a list (not the most natural interface for a tree).

Basically, python already have all the common interfaces, i.e. list,
set, and mapping/dict.

Let's see it like this. In how many ways can a list be implemented?
- Array (python's builtin list)
- Linked List
- Binary Tree
- and the list goes on...

All of them can expose their interface as list, but only array
implementation is available as builtin.

> And I don't have a need because I'm not using Python for my project. If
> I wanted to I couldn't, without implementing myself or porting to Python
> 3 a basic computer science data structure.
> 
>> While Python's motto is "batteries included" I've always felt there
>> was an implicit "but not the kitchen sink" following it. Just because
>> something "could" be useful shouldn't be grounds for inclusion. That's
>> what pypi & the recipes are for. Ideally, little should be created
>> wholesale for the stdlib, what should be added are the existing 3rd
>> party modules that have become so ubiquitous that their presence on
>> any python platform is just expected.
>>   
> 
> Agreed.