<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 4:35 AM, William ML Leslie <span dir="ltr"><<a href="mailto:william.leslie.ttg@gmail.com" target="_blank">william.leslie.ttg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11 July 2017 at 18:22, Rocky Bernstein <<a href="mailto:rb@dustyfeet.com">rb@dustyfeet.com</a>> wrote:<br>
> There's too much generalization and abstraction in the discussion at least<br>
> for me. So let me try to make this a little more concrete with real<br>
> examples. First note that, although Python, yes, does "optimize" "if 0:"<br>
> away, as soon as<br>
> you do something as simple as "debug = 0; if debug:" it is confounded. And<br>
> in my own experience I have done this.<br>
><br>
<br>
</span>Typically DEBUG is a global in the module, which means it can be set<br>
from /outside/ the module, so it's not constant as far as the runtime<br>
is concerned.  Within a function it's a bit wacky sure, and is only<br>
kept around for interactive debugging reasons afaict.<br></blockquote><div><br></div><div>You presume to know much more about the programmer's intentions and behavior than I would care to venture into, or how and why such things could arise. <br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Here's a possible type for `self.a` which illustrates why<br>
CSE/Store-Sinking on a STORE_ATTR is not valid for the example<br>
function `foo`.<br>
<br>
class A(object):<br>
    def set_b(self, value):<br>
        print value<br>
        self._b = value<br>
    b = property(set_b)<br>
<br>
class Example(object):<br>
    def __init__(self):<br>
        self.a = A()<br>
<span class=""><br>
    def foo(self):<br>
        self.a.b = 5<br>
        x = 0<br>
        if x:<br>
            self.a.b = 2<br>
        else:<br>
            return<br>
<br>
</span>Example().foo()<br></blockquote><div><br><br></div><div>Absolutely one can create pathological cases like this. I hope though this isn't your normal mode of coding though.<br><br></div><div>I suspect that this kind of thing doesn't occur often. You know, I encountered something analogous when I first started using Python's code coverage tool, coverage, and the Python style checker flake8. As per Mark Pilgram's original version of Dive into Python I used: <br><br></div><div><span style="font-family:monospace,monospace">if __name__ == '__main__': </span><br><br></div><div>And I was annoyed that older versions of code coverage dinged me because that code was untested code unless I took special care to run it in testing. (Which sometimes I would do). <br><br></div><div>And I suspect most people have run into <i>some</i> annoyance with flake8 and the way it dictates formatting things. <br><br></div><div>So what people typically do <i>if </i>they choose to use coverage or flake8 is add additional comments that clew the tool not to consider that section of the code. As best as I can tell, it works out pretty well. <br></div><div class="h5"><br><br>
--<br>
William Leslie<br>
<br>
Notice:<br>
Likely much of this email is, by the nature of copyright, covered<br>
under copyright law.  You absolutely MAY reproduce any part of it in<br>
accordance with the copyright law of the nation you are reading this<br>
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without<br>
prior contractual agreement.<br>
</div></div><br></div></div>