[issue8379] if __debug__: has nonobvious behaviour when evaluating .pyo without -O
Timothy Fitz timothyf...@gmail.com added the comment: Does that mean you agree that the behavior is a bug? If we're agreed that the behavior is a bug, then it's just a matter of solving the implementation details. One suggestion is to compile in a __debug__ check at the top of every .pyo file, effectively prepending every file with if __debug__ == True: raise AssertionError(). Another could be to add a header to the bytecode (clearly waiting for the next major release of Python). We'll gladly contribute patches once a suitable implementation has been chosen. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8379 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8379] if __debug__: has nonobvious behaviour when evaluating .pyo without -O
Timothy Fitz timothyf...@gmail.com added the comment: In this case bytecode isn't an optimization, it's a distribution choice (this bug reared it's ugly head in our closed-source downloadable client). I think that implausible execution paths are still a bug. Running a .pyo without -O should be explicitly an error. For instance can we change python to reliably blow up at import time? Or implicitly run as if you added -O? -- nosy: +Timothy.Fitz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8379 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Where are list methods documented?
[Tim Peters] The methods on mutable sequence types are documented in the Library manual's section on mutable sequence types: http://docs.python.org/lib/typesseq-mutable.html And like -many- python programmers, when he thinks List he doesn't immediately think Mutable Sequence Type. The title should stay but perhaps the tutorial should be updated to point people in the right direction when they're done and need to know specifics? (This link of the documentation was non-obvious to me also) -- http://mail.python.org/mailman/listinfo/python-list
Re: PyCon Preliminary Program Announced!
I don't care much for parallel tracks myself, because I want to hear basically everything. But we had more proposals of higher quality this year than ever before, so it came down to scheduling more talks in parallel than ever before too, or rejecting perfectly good proposals. Will there be recordings of any of these presentations? There are quite a few times when I want to be at all three tracks at the same time. -- http://mail.python.org/mailman/listinfo/python-list
Zen of Python
While I agree that the Zen of Python is an amazingly concise list of truisms, I do not see any meaning in: Flat is better than nested. I strive for balance between flat and nested. Does anyone have a good example of where this is applied? (specifically to python, or in general) -- http://mail.python.org/mailman/listinfo/python-list
Re: Zen of Python
On 19 Jan 2005 15:24:10 -0800, Carl Banks [EMAIL PROTECTED] wrote: The gist of Flat is better than nested is be as nested as you have to be, no more, because being too nested is just a mess. Which I agree with, and which makes sense. However your gist is a different meaning. It's not that Flat is better than nested it's that Too flat is bad and too flat is nested so be as nested (or as flat) as you have to be and no more. Perhaps Tim Peters is far too concise for my feeble mind wink -- http://mail.python.org/mailman/listinfo/python-list
while 1 vs while True
[ http://www.python.org/moin/PythonSpeed ] Starting with Py2.3, the interpreter optimizes 'while 1' to just a single jump. In contrast while True takes several more steps. While the latter is preferred for clarity, time-critical code should use the first form. Out of pure curiousity, Why wasn't 'While True' optimized also? -- http://mail.python.org/mailman/listinfo/python-list
