[issue1706] Force WINVER 0x0500 (Windows 2000)

Christian Heimes added the comment: The macros don't restrain us to Win2k but they prevent us from using APIs which are not compatible with Windows 2000. It's a compile time option to conditionally exclude new features from the header files. #ifndef NTDDI_VERSION #define NTDDI_VERSION NTDDI_WIN2

[issue1704] possible bug in randint

Rich Marinaccio added the comment: To be clear, I am not using multi-threading in my particular module. I can't explain this behavior with my code alone. The issue is complicated by the fact that my module is called by Civ IV, and I have no idea what the game is doing behind the scenes. I also

[issue1704] possible bug in randint

Raymond Hettinger added the comment: Attaching the whole file isn't a step in the right direction. The preferred approach is to isolate the problem as tightly as possible. This report is dubious because, I can't get the following to fail: from random import seed, randint seed('mystart') while

[issue1704] possible bug in randint

Rich Marinaccio added the comment: What was happening before was I was getting an index out of range error every so often, so then I put in the ValueError catch to see what was going on. I was surprised to see that randIndex was the same as len (preshuffle). I have some further catches in place

[issue1706] Force WINVER 0x0500 (Windows 2000)

Martin v. Löwis added the comment: "The macros don't restrain us to Win2k but they prevent us from using APIs which are not compatible with Windows 2000." --- That's what I meant by "constrain"/restrain: we can't use API that was added in XP directly. For functions, that is a good thing, because

[issue1699] unconditional definiton of _BSD_SOURCE breaks builds with g++-4.3

Martin v. Löwis added the comment: I opted for conditionalizing it to OpenBSD; it was wrong on Linux, anyway, as _BSD_SOURCE has a different meaning there. Fixed in r59610 and r59611. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PRO

[issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2

Vlastimil Brom added the comment: First sorry about a delayed response, but moreover, I fear, preparing a patch would be far beyond my programming competence; sorry about that. __ Tracker <[EMAIL PROTECTED]>

[issue1432] Strange behavior of urlparse.urljoin

Senthil added the comment: If we observe carefully in the urlparse.py and test_urlparse.py, over the releases from Python 2.3 to Python 2.6, the changes required for supporting RFC2396 has been implemented. (RFC2396 replaced 1808 in URL Specification.) But the header of urlparse.py still says it