Stestagg writes:
Having said that, it's a 70-line change, so fixing that up should be trivial once the change has some agreement behind it.
I still don't see a plausible use case that isn't well served by list(view). The OP's "addressing database columns" is superficially plausible, but the indexing mapping is *intended* to be unstable (inserting columns at positions). So the only operation where you can actually use an index would be something like i = db.columns.index("Name") db.columns.insert(i + 1, Address, address_data) because now all indicies > i have been invalidated. But I can't see how having a dict to map names to indicies and simply rebuilding the dict on every change to the list of names is going to be a problem for this application. And of course you'd need to add index and insert methods to support that: things are getting complicated. You say you don't want to copy data out of giant structures. That's a good idea, and of course very much a motivation for the view concept itself. But since views are immutable unless you change the underlying dict, many applications (sorting and creating heaps come to mind) are going to require copying the data. Many applications that don't will require a way to pick out a particular index, which you haven't provided. Yet others process the whole data, which can be iterated (and in particular functools.reduce works as expected). If you don't like the iteration order (eg, because you want an accurate sum() for floats), you need to copy the data (see "sorting and creating heaps"). So what are these use cases? Granted, my imagination may be insufficient, but so far, so are those of the proponents, who all write in terms of "convenience" and other real but very abstract values. On the downside, dicts may be the single most carefully optimized data type in Python, and that effort has clearly been repaid. But it also required a large change in the layout of the data structure. It seems unlikely that that would happen again, but genius is pretty unpredictable. Do we want to further constrain the implementation by requiring support for what seem to be marginally-useful operations? Regards, Steve