homepage

this is a _very_ strange case where the file contents cannot be read,
under msys+wine, but under _just_ wine (cmd.exe) everything goes
absolutely fine.
by moving Py_Initialize() to _before_ the file load, it works!

what is WEIRD_DEBUG? 
why do you remove a test from string_tests.py? 
why do you modify a command in setup.py?
What do you mean "the file contents cannot be read under msys+wine"? 
What specific error you have?
The right thing to do would be to analize that error and fix the 
causes. Randomly flipping blocks of code isn't a good practice.

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

here's a clue:
$ ./python.exe -i
Python 2.5.2 (r252:60911, Jan 16 2009, 10:34:33) [gcc] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> exit()
close failed: [Errno 0] Success
$

here's another clue:
$ ./python.exe 
stdin_is_interactive: 0

here's an updated version, without the cruft.
this has a workaround for the problem of stdin
being seen as not a tty (!) until _after_
Py_Initialize() is run.

Ok, imagine for a moment that your patch is accepted and applied. 
Python runs in a wide variety of systems. Now imagine that, in a few of 
them, it stops running. What would you say to defend your changes? "I 
have no idea why, but it works for me!". I have no doubt your changes 
would be reverted in two nanoseconds, and your chances of getting a 
second patch accepted would drop near zero.
I understand your project and hope you successfully complete your 
goals, but it seems it's not madure enough yet. At this stage, blogging 
about your progresses and writing some sort of recipe would be more 
adequate, until you get a system that builds cleanly and passes most 
(if not all) test cases. This applies to your other pending patches too.
PS: I don't know the English term, but here in Argentina (Spanish) the 
way you "fix" bugs would be called "chapuza". No offense intended.