This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients remi.lapeyre, ronaldoussoren, skrah
Date 2020-06-10.12:14:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1591791299.26.0.993796257046.issue40928@roundup.psfhosted.org>
In-reply-to
Content
I have two observations:

First, I think that the default DEBUG_WRITE_ALWAYS, which is the cause
of this issue, is not C standard conforming -- The standard does not
permit implementation defined diagnostics (global side effects!) on a
completely normal allocation failure.

So I would feel justified to make DEBUG_WRITE_ON_CRASH the default
on Python startup, even if that means that we force that on extension
modules.

That would also address annoyances like in msg327446. Speaking of
which, do you also get that diagnostic in cases like these?


>>> [0] * 10000000000000000
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError


FreeBSD has a similar reporting mechanism, but the default is not
DEBUG_WRITE_ALWAYS.  I suspect DEBUG_WRITE_ALWAYS is there for the
convenience of Apple developers dealing with user reports.


Second, we *could* write such a context manager and it would probably
be okay *for the test suite*, but in general changing a static variable
that is not thread safe at runtime in a library should be avoided.


I don't have OS X at all though. Ronald, what do you think?
History
Date User Action Args
2020-06-10 12:14:59skrahsetrecipients: + skrah, ronaldoussoren, remi.lapeyre
2020-06-10 12:14:59skrahsetmessageid: <1591791299.26.0.993796257046.issue40928@roundup.psfhosted.org>
2020-06-10 12:14:59skrahlinkissue40928 messages
2020-06-10 12:14:58skrahcreate