[pypy-dev] Static bytecode instruction optimization and pypy (JIT?) optimization

Rocky Bernstein rb at dustyfeet.com
Tue Jul 11 04:53:44 EDT 2017


On Tue, Jul 11, 2017 at 4:35 AM, William ML Leslie <
william.leslie.ttg at gmail.com> wrote:

> On 11 July 2017 at 18:22, Rocky Bernstein <rb at dustyfeet.com> wrote:
> > There's too much generalization and abstraction in the discussion at
> least
> > for me. So let me try to make this a little more concrete with real
> > examples. First note that, although Python, yes, does "optimize" "if 0:"
> > away, as soon as
> > you do something as simple as "debug = 0; if debug:" it is confounded.
> And
> > in my own experience I have done this.
> >
>
> Typically DEBUG is a global in the module, which means it can be set
> from /outside/ the module, so it's not constant as far as the runtime
> is concerned.  Within a function it's a bit wacky sure, and is only
> kept around for interactive debugging reasons afaict.
>

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.



> Here's a possible type for `self.a` which illustrates why
> CSE/Store-Sinking on a STORE_ATTR is not valid for the example
> function `foo`.
>
> class A(object):
>     def set_b(self, value):
>         print value
>         self._b = value
>     b = property(set_b)
>
> class Example(object):
>     def __init__(self):
>         self.a = A()
>
>     def foo(self):
>         self.a.b = 5
>         x = 0
>         if x:
>             self.a.b = 2
>         else:
>             return
>
> Example().foo()
>


Absolutely one can create pathological cases like this. I hope though this
isn't your normal mode of coding though.

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:

if __name__ == '__main__':

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).

And I suspect most people have run into *some* annoyance with flake8 and
the way it dictates formatting things.

So what people typically do *if *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.


--
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170711/34836625/attachment.html>


More information about the pypy-dev mailing list