--with-pydebug default compiler flags is a trade-off between "runtime
checks for debug" and performance. -O0 makes Python slower. For
example, we want to Python CI to run as fast as possible.

I don't want to fight for https://bugs.python.org/issue38350 I simply
learnt to type: ./configure --with-pydebug CFLAGS="-O0" (I have a
shell alias for that).

Victor

On Mon, May 24, 2021 at 5:54 PM Guido van Rossum <guido@python.org> wrote:
>
> I'm confused. I've always assumed that --with-pydebug was intended for the situation where you're modifying the C code, so obviously you might have to debug C code. (I know that was the case when we introduced it, decades ago.) If that's not the goal, then what is --py-debug used for?
>
> On Mon, May 24, 2021 at 3:35 AM Victor Stinner <vstinner@python.org> wrote:
>>
>> "Debugging" means many things. Python is built with -Og because it
>> makes Python faster than -O0, and most developers debug Python code,
>> not C code (in gdb).
>>
>> If you don't need to go up to the gdb/lldb level, -Og is fine.
>>
>> It would even make sense to build Python with -O3 in debug mode if you
>> don't debug C code at all, only pure Python code.
>>
>> My proposition to switch to -00 by default was rejected:
>> https://bugs.python.org/issue38350
>>
>> I also love -O0 when I modify C code because it makes the build faster ;-)
>>
>> Fedora Python debug builds are now built with -O0 which makes gdb a
>> way more pleasant experience, not more strange behavior with inlined
>> code or "<optimized out>" local variables or function arguments.
>>
>> Victor
>>
>> On Sun, May 23, 2021 at 3:57 PM Skip Montanaro <skip.montanaro@gmail.com> wrote:
>> >
>> > > I strongly suggest to only build Python with -O0 when using gdb. -Og
>> > > enables too many optimizations which makes gdb less usable.
>> >
>> > Thanks, Victor. It never made sense to me that you would want any
>> > optimizations enabled when truly debugging code (as opposed to wanting
>> > debug symbols and a sane traceback in production code).
>> >
>> > I'm getting more convinced that the problem I'm seeing is a GCC/GDB
>> > thing, particularly because I can move the erroneous stopping point by
>> > changing the GCC optimization level. I'll probably open a bugzilla
>> > report just so it's on that team's radar screen. In the meantime, to
>> > get going again I wrote a crude script which maps the
>> > file:function:label form to file:linenumber form. That way I can
>> > save/restore breakpoints across GDB sessions and still avoid problems
>> > when the offsets to specific instructions change.
>> >
>> > Skip
>> >
>> > Skip
>>
>>
>>
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> _______________________________________________
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-leave@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FPWJHHV55JPF6ZQVI2OGMYSIPYN3AXH2/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)



--
Night gathers, and now my watch begins. It shall not end until my death.