)]}'
{"openstack/orchestration/v1/stack.py":[{"author":{"_account_id":8257,"name":"Brian Curtin","email":"brian@python.org","username":"briancurtin"},"change_message_id":"e12554a13252f2b55fa0fa79ca088b2ac4a85962","unresolved":false,"context_lines":[{"line_number":79,"context_line":"        # heat doesn\u0027t accept resource_key in its request."},{"line_number":80,"context_line":"        return super(Stack, self).create(session, prepend_key\u003dFalse)"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"    def update(self, session):"},{"line_number":83,"context_line":"        # This overrides the default behavior of resource creation because"},{"line_number":84,"context_line":"        # heat doesn\u0027t accept resource_key in its request."},{"line_number":85,"context_line":"        return super(Stack, self).update(session, prepend_key\u003dFalse,"}],"source_content_type":"text/x-python","patch_set":1,"id":"9ad45d7e_b8c5ae5c","line":82,"range":{"start_line":82,"start_character":8,"end_line":82,"end_character":14},"updated":"2016-08-08 16:24:36.000000000","message":"(I\u0027m responding on the update method, but the same comment applies for create)\n\nI\u0027m still not a big fan of passing those parameters just for rare cases like this, when the Resource class was built to be very modular and framework-like so that special cases like orchestration can still fit their usages pretty easily. I know the changes to the base class are setting the default arguments to work as-is everywhere else, the change really only makes this particular feature easier and benefits nothing else. Special cases aren\u0027t special enough to change the API surface in ways that don\u0027t affect the overwhelming majority, as probably 95% of methods don\u0027t need this change.\n\nThis could just as easily be done as follows, which was the intent of how resource2.Resource was built:\n\ndef update(self, session):\n    if not any([self._body.dirty, self._header.dirty]):\n        return self\n\n    request \u003d self._prepare_request(prepend_key\u003dFalse)\n\n    response \u003d session.put(request.uri, endpoint_filter\u003dself.service,\n                           json\u003drequest.body, headers\u003drequest.headers)\n\n    self._translate_response(response, has_body\u003dFalse)\n    return self\n\n\nThat removes the unneeded generality out of the base class and still easily does the three steps needed: prepare, request, translate.\n\nAdditionally, if we were to change the arguments to Resource request methods, in order to do it right we\u0027d change all of the operations to take all of the adjustable arguments like prepend_key and such, but that is clearly not necessary and goes against how this was all built, so I really don\u0027t think we should do this.","commit_id":"e5588fc33adcef99024deafe34748ce9cc36905d"},{"author":{"_account_id":8246,"name":"Qiming Teng","email":"tengqm@outlook.com","username":"tengqm"},"change_message_id":"194efc3ff389d533141c1d9e670f399e15bf3f91","unresolved":false,"context_lines":[{"line_number":79,"context_line":"        # heat doesn\u0027t accept resource_key in its request."},{"line_number":80,"context_line":"        return super(Stack, self).create(session, prepend_key\u003dFalse)"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"    def update(self, session):"},{"line_number":83,"context_line":"        # This overrides the default behavior of resource creation because"},{"line_number":84,"context_line":"        # heat doesn\u0027t accept resource_key in its request."},{"line_number":85,"context_line":"        return super(Stack, self).update(session, prepend_key\u003dFalse,"}],"source_content_type":"text/x-python","patch_set":1,"id":"9ad45d7e_3762083f","line":82,"range":{"start_line":82,"start_character":8,"end_line":82,"end_character":14},"in_reply_to":"9ad45d7e_b8c5ae5c","updated":"2016-08-10 09:48:28.000000000","message":"alright, we have different perceptions about the generality of resource2.Resource. My intention, as you can figure, is to make the base class a little bit \"flexible\" while keep the constraints at each subclasses. Your philosophy as I understand it is keeping the base class more restrictive. For example, \u0027prepend_key\u0027 as a parameter should stay inside the base class. If a service has some special (aka. weird) requirements, we just override the base class\u0027s methods.\n\nThat is fine. I don\u0027t have a strong opinion at it. I\u0027m just feeling that there will be a lot more duplicated code here and there. When we (may) revise the base class, we will have more code to rewrite.","commit_id":"e5588fc33adcef99024deafe34748ce9cc36905d"}]}