On Sat, Aug 01, 2020 at 07:25:42PM +0100, Stestagg wrote:
Irrespective of where in the api this logic should exist, the implementation won't be algorithmically different, (I think, even with a `.ordered` view, as the view would have to cope with changes to the underlying dictionary over its lifetime, and external tracking of changes to dicts is not, afaik, feasible. Unlike for-loop constructs which are inherently scoped, I feel like you wouldn't get away with forbidding modifying a dict() if there's a view on keys/values/items still alive, as these things are first-class objects that can be stored/passed around)
Forbidding mutation of the dict while a view exists is missing the point of having a view in the first place: updating the owning object should update the view as well. -- Steven