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)?
I'm not (anymore) sure that you are aware that the os.stat result
*already* has named fields, in addition to the indexed access. However,
the indexed access is deprecated, and only preserved for backwards
compatibility. So why would a new type be handy for os.stat?
And, if it's not for os.stat, what other uses does it have?
Regards,
Martin
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
