On 2/16/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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.
In the case of os.stat and friends I propose that in Py3k we drop the
tuple-ness completely; it's been dual-op since 2.2.
Maybe Raymond's proposed record type should have two versions: one
that's also a tuple, for compatibility, and one that's just a record.
The compatibility version should also support having named fields that
don't show up in the tuple view -- this has proved very useful for the
os.stat() result.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
