Brett Cannon wrote: > Basically a simple > set interface where we could have a __container__/__view__/__set__ > whatever method to call to get a view of the data structure. > Basically a read-only (with a possible delete possibility) mapping > interface.
If there's an obvious default meaning for the basic access methods like __contains__ and __len__, there's no need for a view to provide these -- the original object can (and should) just implement them itself. Views only come into play when there is more than one possible view of an object (e.g. dict has keys, items, values). Then the details are completely type-specific. There might be room for a general immutable view object that doesn't allow any changes, but that could be provided as a generic wrapper that doesn't need to know anything about the base object or vice versa. > Without a direct reason in terms of the language needing a > standardization of an interface, perhaps we just don't need > views. On the contrary, views are a very useful idea, *as a design pattern*. What we *don't* need in Python, as far as I can see, is any formalised protocols or interfaces for views, because there's nothing that can be said about them in general. Thinking that "having views" means "having a formally defined interface for views" is a mindset that comes from B&D languages like Java. It doesn't apply to Python at all. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
