Since 4075, settings are iterable

[FichteFoll]

Iterating over view.settings() yields a list of (key, value) pairs. That's a non-standard iteration procedure, but something we can certainly work with to provide a proper dict/MutableMapping interface.

Related: sublimehq/sublime_text#3459

[Thom1729]

Do we have a roadmap at this point for what dependencies will look like in 4.0?

[FichteFoll]

No, we have nothing at the moment other than they will be installed into the Lib folder and no loader code will be necessary or even supported.

[deathaxe]

Given sublime.Settings supports most important parts of dict-like access to settings and provides to_dict() method to return native dict representation, whole SublimeDict feels rather obsolete.

Available native API functionality is easy enough to use for relevant use cases.

[FichteFoll]

I did a comparison between our current SettingsDict implementation and what ST4 provides for the 3.8 host (as of build 4199):

• ST does not call __missing__ via __getitem__.
• ST's __delitem__ does not raise a KeyError when a setting is missing.

Additional features that SettingsDict provides:

• subscribe method that wraps the add_on_change more closely to how we expect it to be used.
• __eq__ method that compares the underlying settings id.
• pop, which does not always actually delete the setting when it comes from a fallback settings source.

Features that the native Settings object provides and that we do not use (yet):

• to_dict method.

Features that could be implemented using this to_dict method:

• __iter__
• __len__
• items
• keys
• values
• popitem

Unlike my previous comment (in another issue), ChainMap can generally be used with standard Settings objects for the common dict operations, notably getting, setting and deleting items. Since a ChainMap only applies write operations to the first mapping, the different behavior of deleting keys should not matter in practice.

Some methods, notably popitem, would still be of very questionable use because the items that are iterated over in a View settings object would mostly consist of fallback properties of the application preferences and thus could not be deleted, erased or popped. Also note that the keys of to_dict are always sorted lexicographically, so I don't see any use valid case for this method.

I will file a PR for the remaining ones.