[openstack-dev] "if X not in Y" vs. "if not X in Y" consensus?
mnewby at internap.com
Thu Jan 31 20:32:57 UTC 2013
I'm the reviewer that prompted Zhongyue Luo to ask this question on the mailing list, and would like to chime in.
As has been noted on this thread, not only are the two forms logically equivalent, but they also produce the same byte code. The only reason to mandate one over the other would be 'readability'. I would suggest, though, that the minimal increase in so-called readability does not justify requiring reviewers to enforce this style rule.
That is not to say that I think code consistency is without value - quite the opposite. I subscribe to Ableson/Sussman's view that "Programs must be written for people to read, and only incidentally for machines to execute." I do think, however, that the effort required to enforce a given rule should be weighed carefully against the value that its enforcement brings. I'm not of the opinion that manual effort is justified in this particular case. If the community consensus is that this rule needs to be enforced, I suggest that it be done through automatic detection (ala pep8), or even automatic correction (ala the kinds of code reformatting tools that are pervasive in c/c++ land).
On 2013-01-31, at 7:57 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
> On Jan 31, 2013, at 7:35 AM, Dean Troyer <dtroyer at gmail.com> wrote:
>> On Thu, Jan 31, 2013 at 8:52 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>>> +1 for "X not in Y"
>>> "not X in Y" reads ambiguously to me.
>> And there's the reason it matters...it actually is not ambiguous
>> according to operator precedence rules
>> in "X not in Y" 'not' is part of the membership operator
>> in "not X in Y" 'not' is a boolean operator on X, returning True or False
> The in operator has precedence over not so to have not be an operator on X
> you would need:
> (not X) in Y
> IMO, it seems a little excessive to require one form over the other, but I
> slightly prefer X not in Y as well.
>> These really are different operations that may have the same result
>> for some data types and values. Phew! There is still only one way to
>> do it right...
>> Dean Troyer
>> dtroyer at gmail.com
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev