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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
