On Tue, Jul 28, 2015 at 09:48:25AM -0400, Doug Hellmann wrote: > Excerpts from Gorka Eguileor's message of 2015-07-28 10:37:42 +0200: > > On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote: > > > Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +0000: > > > > Hi Devs, > > > > > > > > X-Openstack-Request-Id. We have analysed python-cinderclient, > > > > python-glanceclient, python-novaclient, python-keystoneclient and > > > > python-neutronclient to check the return types. > > > > > > > > There are 9 ways return values are returned from python clients: > > > > 1. List > > > > 2. Dict > > > > 3. Resource class object > > > > 4. None > > > > 5. Tuple > > > > 6. Exception > > > > 7. Boolean (True/False, for keystoneclient) > > > > 8. Generator (for list api's in glanceclient) > > > > 9. String (for novaclient) > > > > > > > > Out of 9 we have solution for all return types except generator. > > > > In case of glance-client list api's are returning generator which is > > > > immutable. So it is not possible to return request-id in this case, > > > > which is a blocker for adopting the solution. > > > > > > > > I have added detail analysis for above return types in etherpad [2] as > > > > solution #3. > > > > > > > > If you have any suggestion in case of generation type then please let > > > > me know. > > > > > > It should be possible to create a new class to wrap the existing > > > generator and implement the iterator protocol [3]. > > > > > > [3] > > > https://docs.python.org/2/reference/expressions.html#generator-iterator-methods > > > > > > Doug > > > > > > > Unless I'm missing something I think we wouldn't even need to create a > > new class that implements the iterator protocol, we can just return a > > generator that generates from the other one. > > > > For example, for each of the requests, if we get the generator in > > variable *result* that returns dictionaries and we want to add *headers* > > to each dictionary: > > > > return (DictWithHeaders(resource, headers) for resource in result) > > > > Wouldn't that work? > > That would work, but it wouldn't be consistent with the way I read > [2] as describing how the other methods are being updated. > > For example, a method that now returns a list() will return a > ListWithHeaders(), and only that returned object will have the > headers, not its contents. A caller could do:
You are right, it wouldn't be consistent with other methods, and that's not good. So the new iterator class wrapper seems to be the way to go. Gorka. > > response = client.some_method_returning_a_list() > print reponse.headers > > but could not do > > print response[0].headers > > and get the same values. > > Creating a GeneratorWithHeaders class mirrors that behavior for > methods that return generators instead of lists. > > Doug > > > > > [2] https://etherpad.openstack.org/p/request-id > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
