> 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.

That makes sense

> 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
>

It gives:

>>> [0] * 10000000000000000
python3(36633,0x110c08dc0) malloc: can't allocate region
:*** mach_vm_map(size=80000000000004096, flags: 100) failed (error code=3)
python3(36633,0x110c08dc0) malloc: *** set a breakpoint in malloc_error_break to debug
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

Not very nice.

> 
> 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.
> 

What about overriding the default to DEBUG_WRITE_ON_CRASH if MallocDebugReport
is not set? This would be more standard compliant and still let the user 
override it if he whishes so.

> 
> I don't have OS X at all though. Ronald, what do you think?