On Wed, Jun 13, 2012 at 03:13:54PM -0400, R. David Murray wrote: > Again, a program that depends on asserts is buggy. > > As Ethan pointed out we are asking about the case where someone is > *deliberately* setting the .pyo file up to be run as the "normal" > case.
You can't be sure that the .pyo file is there due to *deliberate* choice. It may be accidental. Perhaps the end user has ignorantly deleted the .pyc file, but failed to delete the .pyo file. Perhaps the developer has merely made a mistake. Under current behaviour, deleting the .pyc file shouldn't matter: - if the source file is available, that will be used - if not, a clear error is raised Under the proposed change: - if the source file is *newer* than the .pyo file, it will be used - but if it is missing or older, the .pyo file is used This opens a potential mismatch between the code I *think* is being run, and the actual code being run: I think the .py[c] code is running when the .pyo is actually running. Realistically, we should expect that most people don't *sufficiently* test their apps under -O (if at all!) even if they are aware that there are differences in behaviour. I know I don't, and I know I should. This is just a matter of priority: testing without -O is a higher priority for me than testing with -O and -OO. The consequence is that I may then receive a mysterious bug report that I can't duplicate, because the user correctly reports that they are running *without* -O, but unknown to anyone, they are actually running the .pyo file. > I'm not sure we want to support that, I just want us to be clear > about why we don't :) If I receive a bug report that only occurs under -O, then I immediately suspect that the bug has something to do with assert. If I receive a bug report that occurs without -O, under the proposed change I can't be sure with the optimized code or standard code is running. That adds complexity and confusion. -- Steven _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
