{"action":"opened","issue":{"url":"https://api.github.com/repos/mne-tools/mne-python/issues/2860","repository_url":"https://api.github.com/repos/mne-tools/mne-python","labels_url":"https://api.github.com/repos/mne-tools/mne-python/issues/2860/labels{/name}","comments_url":"https://api.github.com/repos/mne-tools/mne-python/issues/2860/comments","events_url":"https://api.github.com/repos/mne-tools/mne-python/issues/2860/events","html_url":"https://github.com/mne-tools/mne-python/issues/2860","id":132180581,"number":2860,"title":"ENH/API: new contracts and conditions for mne.io.meas_info.Info","user":{"login":"dengemann","id":1908618,"avatar_url":"https://avatars.githubusercontent.com/u/1908618?v=3","gravatar_id":"","url":"https://api.github.com/users/dengemann","html_url":"https://github.com/dengemann","followers_url":"https://api.github.com/users/dengemann/followers","following_url":"https://api.github.com/users/dengemann/following{/other_user}","gists_url":"https://api.github.com/users/dengemann/gists{/gist_id}","starred_url":"https://api.github.com/users/dengemann/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dengemann/subscriptions","organizations_url":"https://api.github.com/users/dengemann/orgs","repos_url":"https://api.github.com/users/dengemann/repos","events_url":"https://api.github.com/users/dengemann/events{/privacy}","received_events_url":"https://api.github.com/users/dengemann/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-02-08T15:58:00Z","updated_at":"2016-02-08T15:58:00Z","closed_at":null,"body":"The recent discussion in #2765 has lead me to discuss with Eric about different ways in which we could improve the Info API to be more clearer. One aspect that maybe was not so clear during the discussion we had over there was the notion of semantic VS code complexity. My idea was that we can have complex implementations but clear APIs that you can quickly conceptualise without exceptions and sub-rules. As it looks now we would have to say: \r\n\r\n\"our info is like a dict but you cannot use the dict API without constraints, as it has some extra behavior, depending on the keys it will be read only and it requires a subclass of list with reduced API for ch_names\"\r\n\r\nMaybe it's time to change the API and introduce explictly a new object with simplified semantics\r\n\r\n\"our info is a read only dict with nice convenience extras, but items cannot be set directly after construction.\"\r\n\r\nit would then allow for a worflow like this:\r\n\r\n```Python\r\n\r\ninfo_as_dict = dict(info)\r\ninfo_as_dict['lowpass'] /= 2\r\ninfo = Info(info_as_dict)\r\n\r\n```\r\nThis could then be the internals of a public or private _update method that takes keyword arguments and hence allows for easier consistency and value checking. It could return a copy to be consistent. We could also use the [FrozenDict pattern](http://stackoverflow.com/questions/2703599/what-would-a-frozen-dict-be)\r\n\r\nIt would also allow us to implement expose a save method etc.\r\n\r\nWe could then send a clear message with the release and have a nice documentation that prepares everyone for this backwards incompatible change (without deprecation)\r\n\r\n@wmvanvliet @Eric89GXL @jasmainak @agramfort, @jona-sassenhagen ..., ...\r\n\r\nLet me know what you think."}}