[Python-Dev] Py2.6 ideas (original) (raw)
Guido van Rossum guido at python.org
Fri Feb 16 19:21:25 CET 2007
- Previous message: [Python-Dev] Py2.6 ideas
- Next message: [Python-Dev] Py2.6 ideas
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2/16/07, Nick Coghlan <ncoghlan at gmail.com> 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/)
- Previous message: [Python-Dev] Py2.6 ideas
- Next message: [Python-Dev] Py2.6 ideas
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]