[openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

Amrith Kumar amrith at tesora.com
Tue Jan 12 13:51:06 UTC 2016


I've tagged this message with the projects impacted by a series of change sets:

	[trove] https://review.openstack.org/#/c/266220/
	[neutron] https://review.openstack.org/#/c/266156/1
	[cinder] https://review.openstack.org/#/c/266099/2
	[swift] https://review.openstack.org/#/c/266185/1
	[ceilometer] https://review.openstack.org/#/c/266211/1
	[nova] https://review.openstack.org/#/c/266143/2
	[keystone] https://review.openstack.org/#/c/266203/2
	[sahara] https://review.openstack.org/#/c/266230/1
	[glance] https://review.openstack.org/#/c/266192/1
	[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how to proceed with this change, and changes like this.

The change, in essence changes a construct of the kind:

if var > 0:
	... something ...

To

if var:
	... something ...

In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to 
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be handled in a consistent way across all projects, maybe with a hacking rule and some discussion on the ML first? After all, if this change is worthwhile, it is worth ensuring that this construct that we are seeking to eliminate, does not reenter the code base.

For what it is worth, I agree with Vitaly Grindev [sahara, in review https://review.openstack.org/#/c/266230/1]. I think the code before the change was more intuitive and readable. 

Thanks,

-amrith




More information about the OpenStack-dev mailing list