db3l.net at gmail.com
Thu Aug 30 22:15:18 CEST 2007
"Martin v. Löwis" <martin at v.loewis.de> writes:
> However, we can't use pywin32 on the buildbot slaves - it's not
Agreed, thus my original suggestion of a standalone wrapper executable
(or using ctypes). But for end users of Python on Windows, this is a
direct Windows-specific API wrapping, for which using the pywin32
wrapper seems appropriate, or if needed, ctypes use is trivial (for a
call taking and returning a single ulong).
>> For this particular case of wanting to use it when developing Python
>> itself, it actually feels a bit more appropriate to me to make the
>> call external to the Python executable under test since it's really a
>> behavior being imposed by the test environment. If a mechanism was
>> implemented to have Python issue the call itself, I'd probably limit
>> it to this specific use case.
> That covers the SetErrorMode case, but not the CRT assertions - their
> messagebox settings don't get inherited through CreateProcess.
Agreed - for Python in debug mode, the CRT stuff needs specific
support (although Thomas' example using ctypes, albeit somewhat ugly,
did manage to still keep out in the test case runner). I can see
exporting access to them in debug builds could be helpful as they
aren't otherwise wrapped.
> Not sure why you want to limit it - I think it's a useful feature on
> its own to allow Python to run without somebody clicking buttons.
> (it would be a useful feature for windows as well to stop producing
> these messages, and report them through some other mechanism).
I just think that if someone needs the functionality they'll have an
easy time with existing methods. And I'm not sure it's something to
encourage average use of, if only because Python (and it's child,
potentially unrelated, processes) will behave differently than other
But it's not like I'm vehemently opposed or anything. At this stage
I'd think having anything that prevented the popups for the buildbots
would be beneficial. Putting it up in the test code (such as
regrtest), seems less intrusive and complicated, even if it involves
slightly ugly code, than deciding how to incorporate it into the
Python core, which could always be done subsequently.
More information about the Python-3000