TLDR: Doing these sort of optimisations on /python/ requires you understand the evaluation model. You can't just do store-sinking like descriptors aren't a thing, and you can't go inlining functions like module globals aren't mutable bindings. #XXTiredCompilation
On 11 July 2017 at 18:53, Rocky Bernstein <r...@dustyfeet.com> wrote: > > > On Tue, Jul 11, 2017 at 4:35 AM, William ML Leslie > <william.leslie....@gmail.com> wrote: >> >> On 11 July 2017 at 18:22, Rocky Bernstein <r...@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. > If the programmer assigns a module-level variable, then the variable should appear to be set in that module. What other intention do you suppose to give this operation? > >> >> 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. > Descriptors - including properties - are a language feature that people should be able to expect to work. You can't just compile their invocation out because you think it will make their program faster. > I suspect that this kind of thing doesn't occur often. I don't think you'll find many in industry that agree with you. Have you *seen* the level of magic behind django, flask, pandas? Have you ever had people bring their super-obscure bugs to you when they run their program with your runtime? > 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). > PSA: don't run your tests directly, use a test runner, and say goodbye to all the awful hacks around getting your path setup correctly and bugs when the tests run against the installed version rather than the version you are editing. -- 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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
