RetroSearch Browse

Fri Feb 16 09:45:16 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-February/071226.html

Martin v. Löwis wrote:
> Raymond Hettinger schrieb:
>> No need to go so widely off-track.  The idea is to have an efficient type that 
>> is directly substitutable for tuples but is a bit more self-descriptive.  I like 
>> to have the doctest result cast at NamedTuple('TestResults failed attempted). 
>> The repr of that result looks like  TestResult(failed=0, attempted=15) but is 
>> still accessible as a tuple and passes easily into other functions that expect a 
>> tuple.  This sort of thing would be handly for things like os.stat(). 
>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
> 
> I'd like to repeat Guido's question: Why does this still need to support 
> the tuple interface (i.e. indexed access)?

So that it remains interoperable with existing libraries that expect a 
tuple? Otherwise you'd be casting (and copying) every time you needed to 
pass it to something that used indexed access.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-February/071226.html below:

[Python-Dev] Py2.6 ideas