Passing an invalid index such as wx.NOT_FOUND to GetString in wx.Choice results in the following error on MAC when using the latest build from the buildbot at http://buildbot.wxpython.org/
C++ assertion ""IsValid(n)"" failed at /Users/robind/projects/bb2/dist-osx-py38/build/ext/wxWidgets/src/osx/choice_osx.cpp(210) in GetString(): wxChoice::GetString(): invalid index.
the macro would provide the expected behavior if wxWidgets is compiled in release mode, but not if it is compiled in debug mode.
So my question, is the buildbot compling wxWidgets in debug mode on purpose? If so, that is fine, I just wanted to make sure. I am also not sure that using the macro is the recommend way of implementing the intended behavior so I am also referencing the issue at https://trac.wxwidgets.org/ticket/18852
Yes, it is intentional. Actually it’s more of a hybrid compilation mode. By default, optimizations are turned on, as well as the flags that will activate the runtime assertions and other runtime checks. Other debug-only flags are not used. It’s done this way because otherwise Python developers would not receive any other indication of what they did wrong[1] , and many of those situations will result in a hard crash in the C++ code if the runtime checks are simply skipped over.
C++ developers will typically have both debug and release mode libraries they can work with, so seeing the assertions and other checks while in development mode and fixing the related issues is the natural order of things, and then they will likely switch to release builds without those runtime checks before deployment. For Python developers it’s a bit different. Except in special cases what they develop with is what they deploy with.
[1] Unless they do their own debug-builds, of course, but many Python developers are not able to do that.