One cannot simply prevent bike-shedding by asking people to do it up front on the mailing list. You'll have to wait until review time like everyone else. ;-)
On Tue, Oct 14, 2014 at 6:04 PM, Angus Lees <g...@inodes.org> wrote: > On Tue, 14 Oct 2014 12:28:29 PM Angus Lees wrote: > > (Context: https://review.openstack.org/#/c/117418/) > > > > I'm looking for some rough consensus on what naming conventions we want > for > > unused variables in Neutron, and across the larger OpenStack python > codebase > > since there's no reason for Neutron to innovate here. > > So after carefully collecting and summarising all one opinion[1], we're > going > with: > > __ (double-underscore) and > _foo (leading underscore) > > > [1] Next time I'll be sure to mention docker in the subject line ;) > > - Gus > > > As far as I can see, there are two cases: > > > > > > 1. The "I just don't care" variable > > > > Eg: _, _, filename = path.rpartition('/') > > > > In python this is very commonly '_', but this conflicts with the gettext > > builtin so we should avoid it in OpenStack. > > > > Possible candidates include: > > > > a. 'x' > > b. '__' (double-underscore) > > c. No convention > > > > > > 2. "I know it is unused, but the name still serves as documentation" > > > > Note this turns up as two cases: as a local, and as a function parameter. > > > > Eg: out, _err = execute('df', path) > > > > Eg: def makefile(self, _mode, _other): > > return self._buffer > > > > I deliberately chose that second example to highlight that the leading- > > underscore convention collides with its use for private properties. > > > > Possible candidates include: > > > > a. _foo (leading-underscore, note collides with private properties) > > b. unused_foo (suggested in the Google python styleguide) > > c. NOQA_foo (as suggested in c/117418) > > d. No convention (including not indicating that variables are > known-unused) > > > > > > As with all style discussions, everyone feels irrationally attached to > their > > favourite, but the important bit is to be consistent to aid readability > > (and in this case, also to help the mechanical code checkers). > > > > Vote / Discuss / Suggest additional alternatives. > > -- > - Gus > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev