[openstack-dev] [nova] is it possible to microversion a static class method?

Christopher Yeoh cbkyeoh at gmail.com
Mon Mar 16 04:26:39 UTC 2015


So ultimately I think this is a style issue rather than a technical one. I
think there
are situations where one way looks clearer than another the other way does.
Sorry I can't get around to putting up a couple of examples,
ATM but to be clear there is no difference in the end result (no different
side effects etc)



On Mon, Mar 16, 2015 at 12:21 PM, Alex Xu <soulxu at gmail.com> wrote:

>
>
> 2015-03-16 9:48 GMT+08:00 Alex Xu <soulxu at gmail.com>:
>
>>
>>
>> 2015-03-13 19:10 GMT+08:00 Sean Dague <sean at dague.net>:
>>
>>> On 03/13/2015 02:55 AM, Chris Friesen wrote:
>>> > On 03/12/2015 12:13 PM, Sean Dague wrote:
>>> >> On 03/12/2015 02:03 PM, Chris Friesen wrote:
>>> >>> Hi,
>>> >>>
>>> >>> I'm having an issue with microversions.
>>> >>>
>>> >>> The api_version() code has a comment saying "This decorator MUST
>>> appear
>>> >>> first (the outermost decorator) on an API method for it to work
>>> >>> correctly"
>>> >>>
>>> >>> I tried making a microversioned static class method like this:
>>> >>>
>>> >>>      @wsgi.Controller.api_version("2.4")  # noqa
>>> >>>      @staticmethod
>>> >>>      def _my_func(req, foo):
>>> >>>
>>> >>> and pycharm highlighted the api_version decorator and complained that
>>> >>> "This decorator will not receive a callable it may expect; the
>>> built-in
>>> >>> decorator returns a special object."
>>> >>>
>>> >>> Is this a spurious warning from pycharm?  The pep8 checks don't
>>> >>> complain.
>>> >>>
>>> >>> If I don't make it static, then pycharm suggests that the method
>>> could
>>> >>> be static.
>>> >>
>>> >> *API method*
>>> >>
>>> >> This is not intended for use by methods below the top controller
>>> level.
>>> >> If you want conditionals lower down in your call stack pull the
>>> request
>>> >> version out yourself and use that.
>>> >
>>> > Both the original spec and doc/source/devref/api_microversions.rst
>>> > contain text talking about decorating a private method.  The latter
>>> > gives this example:
>>> >
>>> >     @api_version("2.1", "2.4")
>>> >     def _version_specific_func(self, req, arg1):
>>> >         pass
>>> >
>>> >     @api_version(min_version="2.5") #noqa
>>> >     def _version_specific_func(self, req, arg1):
>>> >         pass
>>> >
>>> >     def show(self, req, id):
>>> >         .... common stuff ....
>>> >         self._version_specific_func(req, "foo")
>>> >         .... common stuff ....
>>> >
>>> > It's entirely possible that such a private method might not need to
>>> > reference "self", and could therefore be static, so I think it's a
>>> valid
>>> > question.
>>>
>>> That's a doc bug, we should change it.
>>>
>>
>>
>> Actually it is not a bug. It's controversial point in the spec, but
>> finally that was keep in the spec.
>>
>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html
>>
>> The discussion at line 268
>> https://review.openstack.org/#/c/127127/7/specs/kilo/approved/api-microversions.rst
>>
>
> Submit a patch for devref https://review.openstack.org/164555  Let see
> whether we can get agreement....
>
>
>>
>>
>>>
>>>         -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150316/c8e5c6a7/attachment.html>


More information about the OpenStack-dev mailing list