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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5DUYVU2ABLYTNRQUH2RG3WTNVA5C7BAT/
Code of Conduct: http://python.org/psf/codeofconduct/
