[openstack-dev] [nova] is it possible to microversion a static class method?
Chen CH Ji
jichenjc at cn.ibm.com
Mon Mar 16 09:09:56 UTC 2015
oops, duplication ... I submitted changes to spec after got this info since
it make sense to me ...
https://review.openstack.org/#/c/164229/
https://review.openstack.org/#/c/164234/
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM at IBMCN Internet: jichenjc at cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Alex Xu <soulxu at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: 03/16/2015 02:53 AM
Subject: Re: [openstack-dev] [nova] is it possible to microversion a
static class method?
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/8a23fc57/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150316/8a23fc57/attachment.gif>
More information about the OpenStack-dev
mailing list