"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > However, we can't use pywin32 on the buildbot slaves - it's not > installed.
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 applications. 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. -- David _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
