hi gabriel, thanks for looking at this, and my apologies for not editing
the patch to remove debug and other information: i'm in the middle of a
comprehensive porting session.

WEIRD_DEBUG was me endeavouring to find out what the hell is going on

test_str.py segfaulted python under wine due to HAVE_SNPRINTF not being
defined - but that's irrelevant to this issue

likewise ignore the modification to setup.py

regarding the advice to "seek out and understand the cause", i have
to say that i much prefer to ... how can i put this best...

@BEGIN CAVEAT THE FOLLOWING STATEMENTS ARE MADE WITH ABSOLUTELY NO
INTENTION TO CAUSE OFFENSE DO NOT TAKE THIS PERSONALLY IN ANY WAY DO NOT
TAKE IT AS A DELIBERATE INTENT TO OFFEND, CAUSE OFFENSE, CRITICISE OR
OTHERWISE INDICATE MALICIOUS OR HOSTILE INTENT

being absolutely honest: i genuinely do not care about "the cause".
what i care about is "working".  "does it work if this code is moved?
yes."  "does it work if the code is not moved? no".  does it _matter_
if the "cause" is identified? no.

will someone else, possibly in the future, accidentally encounter
or deliberately and actively seek out the "cause"?

possibly.

so - many many apologies for saying this, but i have much better
and more interesting and valuable things to be doing with my time
than _finding out_ why moving specific bits of code "makes things works".

yes it would be nice to know... but i don't care!!

because, most importantly, me _knowing_ makes absolutely xxxx-all
difference to the outcome of whether "it will work" or not.

so, on balance, i'd rather spend my time finding out the additional
code-moving and code-improving required to debug the additional
bug where "python.exe -i" will give me a prompt but "python.exe" with
no arguments will not (and hangs).

@END CAVEAT

gabriel, hi,

debugging python.exe under msys under wine under linux is _really_
tricky.

* gdb.exe under msys under wine under linux not only segfaults
on exit but also refuses to fork() in order to spawn the process
to be debugged!

* strace obviously cannot be used _inside_ msys / wine

* strace _outside_ - on the /usr/bin/wine process - often interferes
with the processes it is tracking, causing them to run out of resources
and also to fail to start up.

* gdb cannot be attached from _outside_ of wine (/usr/bin/winegdb) to
an internal process.

fortunately, segfaults inside wine result in quite a good stacktrace
report, including line numbers and filenames inside python, but in
this case it's "hanging" - and there's something _really_ weird going
on with the stdin, stdout and stderr.

overall, then, the payoff in time invested in "understanding" what
is going on by using non-standard and laborious debugging techniques
is extremely small.

small enough so that, i am very very sorry to say, i'm not going to
put any further time into this _other_ than to _actually_ fix bugs,
rather than "understand" bugs.

it's a development technique that has saved me _vast_ amounts of time.

i never worry about "why" - i just "get on with it".