{"action":"opened","issue":{"url":"https://api.github.com/repos/Lasagne/Lasagne/issues/557","labels_url":"https://api.github.com/repos/Lasagne/Lasagne/issues/557/labels{/name}","comments_url":"https://api.github.com/repos/Lasagne/Lasagne/issues/557/comments","events_url":"https://api.github.com/repos/Lasagne/Lasagne/issues/557/events","html_url":"https://github.com/Lasagne/Lasagne/issues/557","id":123934940,"number":557,"title":"Raise a warning when a keyword passed to `get_output()` is unused","user":{"login":"benanne","id":43829,"avatar_url":"https://avatars.githubusercontent.com/u/43829?v=3","gravatar_id":"","url":"https://api.github.com/users/benanne","html_url":"https://github.com/benanne","followers_url":"https://api.github.com/users/benanne/followers","following_url":"https://api.github.com/users/benanne/following{/other_user}","gists_url":"https://api.github.com/users/benanne/gists{/gist_id}","starred_url":"https://api.github.com/users/benanne/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benanne/subscriptions","organizations_url":"https://api.github.com/users/benanne/orgs","repos_url":"https://api.github.com/users/benanne/repos","events_url":"https://api.github.com/users/benanne/events{/privacy}","received_events_url":"https://api.github.com/users/benanne/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-12-26T15:32:27Z","updated_at":"2015-12-26T15:32:27Z","closed_at":null,"body":"`lasagne.layers.get_output()` can be called with keyword arguments, which are passed to all traversed layers. This makes it possible to control layers with multiple behaviours (e.g. dropout, which can be turned on or off, or batch normalization, which can use minibatch statistics or aggregated statistics).\r\n\r\nThe most common use case for this is the `deterministic` keyword, which is used to turn off any regularizing noise in the net at test time (i.e. dropout).\r\n\r\nThe handling of these keywords is implemented in the `get_output_for()` method of each `Layer` class, which is required to take a catchall `**kwargs` argument to absorb any keywords that the layer doesn't recognize.\r\n\r\nOne issue with this is that a `Layer` instance might unintentionally ignore a certain keyword, and this is basically a silent failure. If you misspell `deterministic` as `determinstic` for example, all layers will ignore it and no warning or exception will be raised.\r\n\r\nThis is not very user friendly. Recently I had a brief discussion about this issue on this reddit thread: https://www.reddit.com/r/MachineLearning/comments/3xom8a/discussion_what_would_you_like_to_see_in_a/cy6hqg8\r\n\r\nOne of the developers of climin ( https://github.com/BRML/climin ) chimed in and pointed me to their solution for this issue: https://github.com/BRML/climin/blob/master/climin/util.py#L140-L151\r\n\r\nBasically, check the called function's argument specification through introspection, and see if any arguments were provided that aren't listed there. If so, raise a warning.\r\n\r\nI think such a solution may be possible for Lasagne as well. We could have `get_output()` inspect the argument specification for all `get_output_for()` calls it makes, and keep track of the set of all accepted keyword arguments across all layers. Once the graph is traversed, we can check whether any of the provided keyword arguments are not in this set.\r\n\r\nAs far as I can tell this would only require modifications in `get_output()` itself. It would complicate the code somewhat, but not excessively so, and I think the usability benefit should not be underestimated.\r\n\r\nThere is one big caveat: not all `get_output_for()` implementations specify all keywords arguments they accept in the method signature. Some implementations work directly with the `kwargs` dictionary, most importantly the new batch normalization implementation (#467).\r\n\r\nSo we'd have to figure out a workaround for that. The simplest approach would be to always have all accepted keyword arguments in the method signature, but I don't know if that is desirable. Another solution would be to provide an alternative way for such methods to 'declare' which keyword arguments they understand, but I think that might get a little too complicated.\r\n\r\nI might try whipping up a PR for this, but before I do that we should probably figure out what to do with accepted keyword arguments that are not explicitly declared in the method signature."}}